Вильям Лам написал наиполезнейшую статью о сбросе/восстановлении пароля консоли сервера VMware ESXi 8 и 7 в составе платформы виртуализации VMware vSphere.

Общее руководство и самый быстрый способ восстановления пароля root для хоста ESXi, если вы забыли или потеряли его, заключается в сбросе с помощью профилей хостов vSphere, если он управлялся сервером vCenter, или просто переустановке ESXi, что позволит сохранить существующие тома VMFS вместе с виртуальными машинами, которые могут на них находиться.

Ранее также было возможно сбросить пароль root ESXi, загрузив систему в Linux и вручную обновив файл /etc/shadow, что похоже на то, как можно сбросить пароль в системе на базе Linux. В сети можно найти множество статей в блогах, описывающих этот процесс. Однако с появлением ESXi Configuration Store данный метод больше не работает для современных версий ESXi, начиная с ESXi 7.0 Update 1 и выше.

Тем не менее, эта тема все еще часто поднимается, особенно в контексте администраторов, которые начинают работать в новой компании, где пароль root ESXi не был должным образом задокументирован, или когда администратору поручено поддерживать набор отдельных ESXi хостов без владельцев. Независимо от сценария, хотя переустановка является самым быстрым способом восстановления, конечно, было бы неплохо сохранить исходную конфигурацию, особенно если нет документации.

Хотя в сети было опубликовано множество фрагментов информации (здесь, здесь и здесь), включая информацию от самого Вильяма, было бы полезно выяснить по шагам актуальный процесс восстановления ESXi 7.x или 8.x хоста без необходимости его переустановки.

Предварительные требования:

• Доступ к физическому носителю, на который установлен ESXi (USB или HDD/SSD)
• Виртуальная машина Linux (Ubuntu или Photon OS)
• Виртуальная машина с вложенным ESXi

Для демонстрации описанного ниже процесса восстановления Вильям установил ESXi 8.0 Update 3c на USB-устройство с базовой конфигурацией (имя хоста, сеть, SSH MOTD), чтобы убедиться в возможности восстановления системы. Затем он изменил пароль root на что-то полностью случайное и удалил этот пароль, чтобы нельзя было войти в систему. Хост ESXi, на котором он "забыл" пароль, будет называться физическим хостом ESXi, а вложенная виртуальная машина с ESXi, которая будет помогать в восстановлении, будет называться вложенным хостом (Nested ESXi).

Шаг 1 — Разверните вложенную виртуальную машину с ESXi (скачать с сайта VMware Flings), версия которой должна соответствовать версии вашего физического хоста ESXi, который вы хотите восстановить.

Шаг 2 — Скопируйте файл state.tgz с физического хоста ESXi, который вы хотите восстановить. Обязательно сделайте резервную копию на случай, если допустите ошибку.

• Если ваш хост ESXi установлен на USB, отключите USB-устройство, подключите его к настольной системе и скопируйте файл с тома BOOTBANK1.
• Если ваш хост ESXi установлен на HDD/SSD, вам нужно будет загрузить физическую систему с помощью Linux LiveCD (Ubuntu или Knoppix) и смонтировать раздел 5 для доступа к файлу state.tgz.

Шаг 3 — Скопируйте файл state.tgz с вашего физического хоста ESXi на вложенный хост ESXi и поместите его в /tmp/state.tgz, затем выполните следующую команду для извлечения содержимого файла:

tar -zxvf state.tgz
rm -f state.tgz

Шаг 4 — Войдите на ваш вложенный хост ESXi и выполните следующие команды для извлечения его файла state.tgz, который будет помещен в каталог /tmp/a. Затем мы используем утилиту crypto-util для расшифровки файла local.tgz.ve вложенного хоста ESXi, чтобы получить файл local.tgz, и затем просто удаляем зашифрованный файл вместе с файлом encryption.info вложенного хоста ESXi. После этого мы заменим их файлом encryption.info с нашего физического хоста ESXi и создадим модифицированную версию state.tgz, которая будет загружаться в нашей вложенной виртуальной машине ESXi. Мы используем это для расшифровки исходного файла state.tgz с нашего физического хоста ESXi.

mkdir /tmp/a
cd /tmp/a
tar xzf /bootbank/state.tgz
crypto-util envelope extract --aad ESXConfiguration local.tgz.ve local.tgz
rm -f local.tgz.ve encryption.info
cp /tmp/encryption.info /tmp/a/encryption.info
tar -cvf /tmp/state-mod.tgz encryption.info local.tgz

После успешного выполнения последней команды, нам нужно скопировать файл /tmp/state-mod.tgz на ваш рабочий стол, а затем выключить вложенную виртуальную машину ESXi.

Шаг 5 — Смонтируйте первый VMDK диск из вашей вложенной виртуальной машины ESXi на вашу виртуальную машину с Linux. В данном случае Вильм использует Photon OS, который также управляет и DNS-инфраструктурой.

Шаг 6 — Убедитесь, что VMDK вашей вложенной виртуальной машины ESXi виден в вашей системе Linux, выполнив следующую команду. Мы должны увидеть два раздела bootbank (5 и 6), как показано на скриншоте ниже:

fdisk -l

Шаг 7 — Перенесите файл state-mod.tgz, созданный на Шаге 4, на вашу виртуальную машину с Linux, затем смонтируйте оба раздела bootbank и замените файл state.tgz на нашу модифицированную версию.

mount /dev/sdb5 /mnt
cp ~/state-mod.tgz /mnt/state.tgz -f
chmod 755 /mnt/state.tgz
umount /mnt

mount /dev/sdb6 /mnt
cp ~/state-mod.tgz /mnt/state.tgz -f
chmod 755 /mnt/state.tgz
umount /mnt

Примечание: Этот шаг необходим, потому что, если вы просто скопируете модифицированный файл state.tgz напрямую на USB-устройство физического хоста ESXi, вы обнаружите, что система восстановит оригинальный файл state.tgz, даже если на обоих разделах содержится модифицированная версия.

Шаг 8 — Сделайте remove (не удаляйте) VMDK файл вложенной виртуальной машины ESXi с виртуальной машины Linux, затем включите вложенную виртуальную машину ESXi.

После успешной загрузки вложенной виртуальной машины ESXi, она теперь работает с оригинальным файлом encryption.info с нашего физического хоста ESXi, что позволит нам восстановить исходный файл state.tgz.

Шаг 9 — Скопируйте исходный файл state.tgz, созданный на Шаге 2, во вложенную виртуальную машину ESXi, поместите его в каталог /tmp/state.tgz и выполните следующую команду, которая теперь позволит нам расшифровать файл state.tgz с физического хоста ESXi, как показано на скриншоте ниже!

cd /tmp
tar -zxvf state.tgz
rm -f state.tgz
crypto-util envelope extract --aad ESXConfiguration local.tgz.ve local.tgz
rm -f local.tgz.ve

Шаг 10 — После расшифровки исходного файла state.tgz у нас должен появиться файл local.tgz, который мы извлечем локально в каталоге /tmp, выполнив следующую команду:

Следующие три каталога: .ssh, etc/ и var/ будут размещены в /tmp, а /tmp/var/lib/vmware/configstore/backup/current-store-1 — это хранилище конфигурации ESXi для физического хоста ESXi, которое нам нужно обновить и заменить оригинальный хеш пароля root на желаемый, чтобы мы могли войти в систему.

Для непосредственного изменения хранилища конфигурации ESXi нам необходимо использовать утилиту sqlite3, так как файл хранится в виде базы данных sqlite3. Мы можем выполнить следующую команду на вложенной виртуальной машине ESXi, чтобы проверить текущий хеш пароля root:

/usr/lib/vmware/sqlite/bin/sqlite3 /tmp/var/lib/vmware/configstore/backup/current-store-1  "select * from config where Component='esx' and ConfigGroup = 'authentication' and Name = 'user_accounts' and Identifier = 'root'"

Шаг 11 — Вам потребуется новый хеш пароля в формате SHA512, где вы знаете сам пароль, после чего выполните следующую команду, заменив хеш.

/usr/lib/vmware/sqlite/bin/sqlite3 /tmp/var/lib/vmware/configstore/backup/current-store-1  "update config set UserValue='{\"name\":\"root\",\"password_hash\":\"\$6\$s6ic82Ik\$ER28x38x.1umtnQ99Hx9z0ZBOHBEuPYneedI1ekK2cwe/jIpjDcBNUHWHw0LwuRYJWhL3L2ORX3I5wFxKmyki1\",\"description\":\"Administrator\"}' where Component='esx' and ConfigGroup = 'authentication' and Name = 'user_accounts' and Identifier = 'root'"

Примечание: Вам нужно правильно экранировать любые специальные символы, например, как в приведенном выше примере, где хеш пароля содержит символ "$". Чтобы убедиться, что замена хеша выполнена правильно, вы можете выполнить вышеуказанную команду запроса, чтобы убедиться, что вывод соответствует желаемому хешу пароля, как показано на скриншоте ниже.

Шаг 12 — Теперь, когда мы обновили хранилище конфигурации ESXi с нашим желаемым паролем root, нам нужно заново создать файл state.tgz, который будет содержать наши изменения, выполнив следующие команды:

rm -f local.tgz 
tar -cvf /tmp/local.tgz .ssh/ etc/ var/ 
tar -cvf /tmp/state-recover.tgz encryption.info local.tgz

Скопируйте файл /tmp/state-recover.tgz с вложенной виртуальной машины ESXi на вашу виртуальную машину с Linux, которая затем будет использоваться для монтирования носителя физического хоста ESXi, чтобы заменить файл state.tgz на нашу восстановленную версию.

Шаг 13 — Смонтируйте носитель физического хоста ESXi на вашу виртуальную машину с Linux. Поскольку физический хост ESXi установлен на USB, можно просто подключить USB-устройство напрямую к виртуальной машине с Linux.

Снова мы можем убедиться, что виртуальная машина с Linux видит носитель с установленным физическим хостом ESXi, выполнив команду fdisk -l, и мы должны увидеть два раздела bootbank (5 и 6), как показано на скриншоте ниже.

Шаг 14 — Теперь нам просто нужно смонтировать раздел bootbank и заменить оригинальный файл state.tgz на нашу модифицированную версию (state-recover.tgz).

mount /dev/sdb5 /mnt 
cp ~/state-recover.tgz /mnt/state.tgz 
chmod 755 /mnt/state.tgz 
umount /mnt

Примечание: Поскольку физический хост ESXi был только что установлен, на втором разделе bootbank не было ничего для замены, но если вы найдете файл state.tgz, его также следует заменить, используя ту же команду, но указав другой номер раздела.

Шаг 15 — Последний шаг: размонтируйте носитель физического хоста ESXi с виртуальной машины Linux, затем включите ваш физический хост ESXi, и теперь вы сможете войти в систему, используя обновленный пароль root!

Блогер Дункан Эппинг записал отличное видео по теме защиты данных кластеров отказоустойчивости средствами продукта VMware vSAN Data Protection для VMware Explore в Лас-Вегасе и Барселоне. Так как ему поступали вопросы от людей по поводу защиты данных vSAN, он решил поделиться демо на YouTube и опубликовать его в своем блоге. Ранее он выпустил несколько статей о защите данных vSAN и стал замечать, что некоторые клиенты начинают тестировать эту функцию и даже использовать её в производственных средах, где это возможно. Как мы также писали ранее, решение vSAN Data Protection доступно только только в рамках архитектуры vSAN ESA, так как она использует новые возможности создания моментальных снимков (снапшотов). Также полностью новый интерфейс был представлен в средстве управления Snap Manager Appliance. Обязательно скачайте, разверните и настройте его в первую очередь.

Собственно, само демо VMware vSAN Data Protection, которое стоит посмотреть, если вы интересуетесь защитой данных в рамках виртуальной инфраструктуры VMware vSphere и vSAN:

Вчера мы писали об обновленной утилите SexiGraf для мониторинга виртуальной инфраструктуры VMware vSphere. Сегодня мы поговорим еще об одном наборе бесплатных дэшбордов Grafana для мониторинга VMware vSphere, которые сделал Jorge de la Cruz.

Больше 4 лет назад мы писали об этих дэшбордах, но наш читатель Сергей указал на то, что с тех пор эти дэшборды были обновлены, кроме того появилась отличная инструкция по тому, как собрать и настроить все компоненты, имея только сервер vCenter, чтобы все эти дэшборды начали отображать ваши метрики.

Итак, сами дэшборды:

1. VMware vSphere - Overview

Этот дэшборд содержит пять различных разделов: один для мониторинга производительности ESXi и vCenter, другой для производительности виртуальных машин, третий для дисков, четвёртый для хранилищ, и последний для хостов и их IPMI. Дэшборд включает переменные, чтобы сделать его использование проще и подходящим для различных типов рабочих нагрузок. Индикаторы автоматически настраиваются в зависимости от выбранных вами хранилищ данных. Если у вас много хранилищ, рассмотрите возможность изменения параметра Min Width для Repeat Panel.

Здесь визуализуются все высокоуровневые параметры виртуальной инфраструктуры, такие как загрузка ресурсов кластера, заполненность хранилищ, состояние гипервизора и использование ресурсов виртуальными машинами:

2. VMware vSphere - Datastore

Этот дэшборд содержит два раздела: один для мониторинга производительности ESXi и vCenter, другой - для производительности виртуальных машин. Дашборд включает переменные, чтобы упростить его использование и сделать его подходящим для различных типов рабочих нагрузок. Индикаторы автоматически настраиваются в зависимости от выбранных вами хранилищ данных. Если у вас много хранилищ, рассмотрите возможность изменения параметра Min Width для Repeat Panel.

Здесь мы можем увидеть загрузку емкости датасторов, параметры чтения-записи, а также суммарные показатели для используемой и свободной емкости:

3. VMware vSphere - Hosts

Тут видны основные метрики с уровня хоста для каждого из серверов ESXi: конечно же, загрузка аппаратных ресурсов и сети, а также дисковые задержки (latency):

4. VMware vSphere - VMs

Здесь можно увидеть самые полезные метрики для всех виртуальных машин вашего датацентра. Здесь можно увидеть аптайм, загрузку системных ресурсов и сети, latency, счетчик CPU Ready и другое:

Ну и главное - вот эта статья. Она описывает, как настроить мониторинг VMware с помощью дэшбордов Grafana, InfluxDB и Telegraf. В ней пошагово объясняется создание стека контейнеров с использованием Docker Compose, настройка InfluxDB и Telegraf для сбора метрик VMware из vCenter, а также визуализация данных в Grafana. Там подробно рассматривается использование готовых дэшбордов для ускорения процесса настройки и предлагаются советы по устранению неполадок.

Спасибо Сергею за новость.

Наш читатель Сергей справедливо заметил, что мы давно не писали о новых релизах бесплатной утилиты SexiGraf, предназначенной для мониторинга виртуальной инфраструктуры VMware vSphere. В последний раз мы писали об этом в январе прошлого года, а на днях вышло обновление этого продукта - SexiGraf 0.99k (Lighthouse Point).

Это средство было сделано энтузиастами (Raphael Schitz и Frederic Martin) в качестве альтернативы платным продуктам для мониторинга серверов ESXi и виртуальных машин. Представления SexiPanels для большого числа метрик в различных разрезах есть не только для VMware vSphere и vSAN, но и для ОС Windows и FreeNAS.

Давайте посмотрим на новые возможности двух недавних релизов:

Релиз Lighthouse Point (0.99k) от 7 октября 2024

VMware Snapshot Inventory

Начиная с версии SexiGraf 0.99h, панель мониторинга «VI Offline Inventory» заменена на VMware Inventory с инвентаризацией ВМ, хостов и хранилищ данных (вскоре добавятся портгруппы и другие элементы). Эти новые панели имеют расширенные возможности фильтрации и значительно лучше подходят для крупных инфраструктур (например, с более чем 50 000 виртуальных машин). Это похоже на извлечение данных из RVtools, которое всегда отображается и актуально.

В релизе v0.99k появилось представление VM Snapshot Inventory:

Улучшения "Cluster health score" для VMware vSAN 8

Вместо того чтобы бесконечно нажимать на кнопку обновления на вкладке «Resyncing Components» в WebClient, начиная с версии SexiGraf 0.99b разработчики добавили панель мониторинга vSAN Resync:

Shell In A Box

В версии SexiGraf 0.99k разработчики добавили отдельный дэшборд Shell In A Box за обратным прокси-сервером, чтобы снова сделать отладку удобной.

Прочие улучшения:

• Официальная поддержка vSphere и vSAN 8.3 API, а также Veeam Backup & Replication v12
• Движок обновлен до Grafana 8.5.9
• PowerShell core обновлен до 7.4.4 LTS
• PowerCLI 13.3
• Graphite 1.2.0
• Автоматическая очистка /var/lib/grafana/png/
• Добавлен выбор версии в панель мониторинга VMware Evo Version
• Добавлена многострочная панель в панель мониторинга репозиториев Veeam
• Обработка учетных записей с очень ограниченными правами
• Опция использования MAC-адреса вместо Client-ID при использовании DHCP
• Добавлено имя хоста гостевой ОС в инвентаризацию виртуальных машин

Релиз St. Olga (0.99j) от 12 февраля 2024

В этой версии авторы добавили официальную поддержку новых API vSphere и vSAN 8.2, а также Veeam Backup & Replication v11+.

Новые возможности:

• Поддержка Veeam Backup & Replication
• Автоматическое слияние метрик ВМ и ESXi между кластерами (функция DstVmMigratedEvent в VROPS)
• Количество путей до HBA
• PowerShell Core 7.2.17 LTS
• PowerCLI 13.2.1
• Grafana 8.5.9 (не 8.5.27 из-за ошибки, появившейся в v8.5.10)
• Ubuntu 20.04.6 LTS

Улучшения и исправления:

• Метрика IOPS для виртуальных машин
• Инвентаризация VMware VBR
• История инвентаризации
• Панель мониторинга эволюции версий активов VMware
• Исправлено пустое значение datastoreVMObservedLatency на NFS
• Различные исправления ошибок

SexiGraf теперь поставляется только в виде новой OVA-аппаратной версии, больше никаких патчей (за исключением крайних случаев). Для миграции необходимо использовать функцию Export/Import, чтобы извлечь данные из вашей предыдущей версии SexiGraf и перенести их в новую.

Актуальная версия SexiGraf доступна для бесплатной загрузки на странице Quickstart.

Недавно мы писали о технологии NVMe Tiering, которая появилась в режиме технологического превью в платформе VMware vSphere 8.0 Update 3.

Memory Tiering использует более дешевые устройства в качестве памяти. В Update 3 платформа vSphere использует флэш-устройства PCIe на базе NVMe в качестве второго уровня памяти, что увеличивает доступный объем памяти на хосте ESXi. Memory Tiering через NVMe оптимизирует производительность, распределяя выделение памяти виртуальных машин либо на устройства NVMe, либо на более быструю динамическую оперативную память (DRAM) на хосте. Это позволяет увеличить объем используемой памяти и повысить емкость рабочих нагрузок, одновременно снижая общую стоимость владения (TCO).

Вильям Лам написал интересный пост о выводе информации для NVMe Tiering в VMware vSphere через API. После успешного включения функции NVMe Tiering, которая была введена в vSphere 8.0 Update 3, вы можете найти полезную информацию о конфигурации NVMe Tiering, перейдя к конкретному хосту ESXi, затем выбрав "Configure" -> "Hardware" и в разделе "Memory", как показано на скриншоте ниже.

Здесь довольно много информации, поэтому давайте разберём отдельные элементы, которые полезны с точки зрения NVMe-тиринга, а также конкретные vSphere API, которые можно использовать для получения этой информации.

Memory Tiering Enabled

Поле Memory Tiering указывает, включён ли тиринг памяти на хосте ESXi, и может иметь три возможных значения: "No Tiering" (без тиринга), "Hardware Memory Tiering via Intel Optane" (аппаратный тиринг памяти с помощью технологии Intel Optane) или "Software Memory Tiering via NVMe Tiering" (программный тиринг памяти через NVMe). Мы можем получить значение этого поля, используя свойство "memoryTieringType" в vSphere API, которое имеет три перечисленных значения.

Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:

(Get-VMHost "esxi-01.williamlam.com").ExtensionData.Hardware.MemoryTieringType

Tier 0 Memory

Поле Tier 0 представляет общий объём физической оперативной памяти (DRAM), доступной на хосте ESXi. Мы можем получить это поле, используя свойство "memoryTierInfo" в vSphere API, которое возвращает массив результатов, содержащий значения как Tier 0, так и Tier 1.

Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:

((Get-VMHost "esxi-01.williamlam.com").ExtensionData.Hardware.MemoryTierInfo | where {$_.Type -eq "DRAM"}).Size

Tier 1 Memory

Поле Tier 1 представляет общий объём памяти, предоставляемой NVMe-тирингом, которая доступна на хосте ESXi. Мы можем получить это поле, используя свойство "memoryTierInfo" в vSphere API, которое возвращает массив результатов, содержащий значения как Tier 0, так и Tier 1.

Примечание: Можно игнорировать термин "Unmappable" — это просто другой способ обозначения памяти, отличной от DRAM.

Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:

((Get-VMHost "esxi-01.williamlam.com").ExtensionData.Hardware.MemoryTierInfo | where {$_.Type -eq "NVMe"}).Size

Поле Total представляет общий объём памяти, доступный ESXi при объединении как DRAM, так и памяти NVMe-тиринга, который можно агрегировать, используя размеры Tier 0 и Tier 1 (в байтах).

Устройства NVMe для тиринга

Чтобы понять, какое устройство NVMe настроено для NVMe-тиринга, нужно перейти в раздел "Configure" -> "Storage" -> "Storage Devices", чтобы просмотреть список устройств. В столбце "Datastore" следует искать значение "Consumed for Memory Tiering", как показано на скриншоте ниже. Мы можем получить это поле, используя свойство "usedByMemoryTiering" при энумерации всех устройств хранения.

Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:

$storageSystem = Get-View (Get-vmhost "esxi-01.williamlam.com").ExtensionData.ConfigManager.StorageSystem
($storageSystem.StorageDeviceInfo.ScsiLun | where {$_.UsedByMemoryTiering -eq $true}).CanonicalName

Соотношение NVMe-тиринга и DRAM

Отношение объёма DRAM к NVMe по умолчанию составляет 25% и настраивается с помощью следующего расширенного параметра ESXi под названием "Mem.TierNvmePct". Мы можем получить значение этого поля, используя либо vSphere API ("OptionManager"), либо через ESXCLI.

Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:

(Get-vmhost "esxi-01.williamlam.com" | Get-AdvancedSetting -Name Mem.TierNvmePct).Value

Сводный отчёт

Вильям собрал все вышеперечисленные парметры и создал скрипт PowerCLI под названием "get-nvme-tiering-info.ps1", который предоставляет удобное резюме для всех хостов ESXi в рамках конкретного кластера Sphere (вы также можете изменить скрипт, чтобы он запрашивал конкретный хост ESXi). Это может быть полезно для быстрого получения информации о хостах, на которых NVMe-тиринг может быть настроен (или нет).

Вот скриншот того, как выглядит вывод скрипта:

Дункан Эппинг написал интересный пост.

Начиная с обновления VMware vSphere 8.0 Update 2, поддержка опции "None - Stretched Cluster" в политике хранения (Storage Policy) для конфигурации vSAN Stretched Cluster была удалена. Причина этого заключается в том, что данная опция часто приводила к ситуациям, когда клиенты ошибочно ее использовали, и при сбое обнаруживали, что некоторые виртуальные машины перестали работать.

Причиной остановки работы виртуальных машин было то, что в соответствии с этой политикой все компоненты объекта размещались в одном месте, но не было гарантии, что все объекты одной виртуальной машины будут находиться на одном сайте. Таким образом, могла возникнуть ситуация, показанная ниже, когда виртуальная машина работает на сайте B, один из ее объектов данных хранится на сайте A, другой объект данных на сайте B, и, кроме того, свидетель также находится в сайте B. К сожалению, у некоторых клиентов это приводило к странному поведению, если возникали проблемы с сетью между Сайтами A и B.

Поэтому данную опцию было решено убрать.

Одним из самых больших препятствий в управлении инфраструктурой частного облака является координация с владельцами приложений для планирования временных окон обслуживания, которые соответствуют потребностям их бизнеса. К счастью, VMware vSphere с возможностями живой миграции vMotion и Storage vMotion предлагает решение этой проблемы, обеспечивая проверенные обновления инфраструктуры без простоев. Однако, даже с преимуществами vMotion, бизнес-политики могут всё равно диктовать время и выполнение определённых операций, подчёркивая необходимость минимизировать количество операций по обслуживанию, где это возможно. Уменьшая число таких операций, ИТ-команды могут минимизировать сбои, снизить затраты и повысить общую эффективность инфраструктуры.

Обновление и патчинг в одном рабочем процессе

Одним из ключевых улучшений в VMware Cloud Foundation 5.2 является новая функция под названием «Flexible Bill of Materials (BOM)», которая позволяет выбирать конкретные версии отдельных компонентов во время обновления домена рабочих нагрузок (workload domain). Это упрощает процесс обновления, сокращая количество операций по обслуживанию и минимизируя простои. В предыдущих версиях VCF процесс требовал двух операций обслуживания: одной для обновления и второй для применения асинхронного патча. Теперь же гибкий BOM в VCF 5.2 упрощает процесс, снижая административную нагрузку и потенциальные риски.

Выглядит это следующим образом (кликните на картинку, чтобы открыть анимацию):

Теперь во время процесса обновления администраторам VCF предоставляется возможность выбрать другую целевую версию компонента. Если доступны, они могут выбрать из дополнительных версий, известных как асинхронные патчи – обновления, выпущенные отдельно от списка компонентов (BOM), которые можно применить, обеспечивая большую гибкость в процессе обновления. Применимость этих асинхронных патчей определяется автоматически на основе метаданных, полученных из онлайн-репозитория. Это гарантирует, что администратору будут предложены только совместимые и актуальные патчи.

Также на эту тему есть хорошее обзорное видео от VMware:

Улучшения VCF 5.2 в управлении жизненным циклом

Помимо опции гибкого списка компонентов (BOM), VCF 5.2 вводит несколько других улучшений, упрощающих процесс обновления и развертывания. Например, администраторы VCF теперь могут применять асинхронные патчи напрямую через интерфейс SDDC Manager, что упрощает поддержание актуальности среды. Процесс развертывания доменов рабочих нагрузок также был оптимизирован: асинхронные патчи автоматически включаются, чтобы обеспечить более безопасные и актуальные новые развертывания.

VCF 5.2 также вводит новый масштабируемый подход к зеркалированию онлайн-хранилища на локальный сервер, обеспечивая легкий доступ к последним патчам и обновлениям даже в изолированных или автономных средах. Эта функция особенно полезна для организаций с жесткими требованиями безопасности или ограниченным доступом к интернету, так как она гарантирует, что последние патчи и обновления всегда доступны для развертывания.

Компания VMware представила обновленную версию документа "Best Practices for VMware vSphere 8.0 Update 3", описывающего лучшие практики повышения производительности для последней версии платформы VMware vSphere 8.0 Update 3 — ценный ресурс, наполненный экспертными советами по оптимизации быстродействия. Хотя это и не является всеобъемлющим руководством по планированию и настройке ваших развертываний, он предоставляет важные рекомендации по улучшению производительности в ключевых областях.

Краткий обзор содержания:

• Глава 1: Оборудование для использования с VMware vSphere (Стр. 11) — узнайте важные советы по выбору правильного оборудования, чтобы максимально эффективно использовать вашу среду vSphere.
• Глава 2: ESXi и виртуальные машины (Стр. 25) — ознакомьтесь с лучшими практиками для платформы VMware ESXi и тонкими настройками виртуальных машин, работающих в этой среде.
• Глава 3: Гостевые операционные системы (Стр. 57) — узнайте, как правильно оптимизировать гостевые ОС, работающие в ваших виртуальных машинах vSphere.
• Глава 4: Управление виртуальной инфраструктурой (Стр. 69) — получите советы по эффективному управлению для поддержания высокопроизводительной виртуальной инфраструктуры.

Независимо от того, хотите ли вы грамотно настроить свою систему или просто ищете способы повышения эффективности, этот документ является отличным справочником для обеспечения максимальной производительности вашей среды VMware vSphere.

vSphere Memory Tiering - это очень интересная функция, которую VMware выпустила в качестве технического превью в составе vSphere 8.0 Update 3, чтобы дать своим клиентам возможность оценить механику ранжирования памяти в их тестовых средах. Об этом мы уже немного рассказывали, а сегодня дополним.

По сути, Memory Tiering использует более дешевые устройства в качестве памяти. В vSphere 8.0 Update 3 vSphere использует флэш-устройства PCIe на базе NVMe в качестве второго уровня памяти, что увеличивает доступный объем памяти на хосте ESXi. Memory Tiering через NVMe оптимизирует производительность, распределяя выделение памяти виртуальных машин либо на устройства NVMe, либо на более быструю динамическую оперативную память (DRAM) на хосте. Это позволяет увеличить объем используемой памяти и повысить емкость рабочих нагрузок, одновременно снижая общую стоимость владения (TCO).

Memory Tiering также решает проблемы несоответствия между ядрами процессора и объемом памяти и способствует лучшей консолидации рабочих нагрузок и виртуальных машин.

Memory Tiering настраивается на каждом ESXi в кластере, и все хосты должны работать на vSphere 8.0 U3. По умолчанию соотношение DRAM к NVMe составляет 4:1, но его можно изменить для использования большего количества ресурсов NVMe в качестве памяти.

Для изменения этого соотношения нужно зайти в Host > Manage > System > Advanced settings и поменять там настройку Mem.TierNvmePct. По умолчанию это 25, то есть NVMe занимает 25% от общей оперативной памяти хоста ESXi. Максимальное значение составляет 400, минимальное - 1.

Технические подробности настройки vSphere Memory Tiering описаны в статье базы знаний KB 95944. Там можно скачать документ "Memory Tiering over NVMe Tech Preview", где описываются все аспекты использования данной технологии:

Если же вы хотите посмотреть на работу этой штуки в действии, то можете почитать интересные посты Вильяма Лама:

• NVMe Tiering in vSphere 8.0 Update 3 is a Homelab game changer!
• Quick Tip - NVMe Tiering configured but not working?

На конференции VMware Explore 2024, вместе с презентацией новой версии платформы VMware Cloud Foundation 9, Broadcom также объявила о планах разработки следующего поколения VMware vSphere Virtual Volumes (vVols). Следующее поколение vVols будет преследовать три основные цели: обеспечить согласованный и оптимизированный пользовательский опыт на разных платформах хранения, адаптировать vVols для современных масштабируемых задач, таких как рабочие нагрузки AI/ML и развёртывания облачных провайдеров, а также полностью интегрироваться с VMware Cloud Foundation (VCF).

vVols использует управление на основе политик хранилищ (Storage Policy-Based Management, SPBM) для оптимизации операций и минимизации потребности в специализированных навыках для работы с инфраструктурой хранения. vVols устраняет необходимость в ручном предоставлении хранилища, заменяя это описательными политиками на уровне ВМ или VMDK, которые могут быть применены или обновлены через простой рабочий процесс.

Клиенты продолжают активно внедрять VMware Cloud Foundation, и они хотят интегрировать свои существующие решения для хранения в VCF, чтобы максимизировать свою отдачу от инвестиций. Они стремятся начать путь к полностью программно-определяемому подходу к инфраструктуре, упрощая операции хранения и интегрируясь с облачными возможностями управления, встроенными в частную облачную платформу VCF. По мере того, как клиенты запускают всё больше рабочих нагрузок на массивы, поддерживающие vVols, требования к производительности, масштабу и защите данных продолжают расти, поэтому vVols должен развиваться, чтобы удовлетворять эти потребности.

Планируемые преимущества следующего поколения vVols для клиентов включают:

• Полная интеграция с VMware Cloud Foundation: установка, развертывание и управление хранилищем с VCF, пригодность для использования в качестве основного и дополнительного хранилища для всех доменов рабочих нагрузок.
• Прописанная модель VASA для обеспечения согласованного и оптимизированного пользовательского опыта на всех платформах хранения.
• Поддержка масштабируемых сценариев использования для облаков.
• Обеспечение высокой доступности и развертывания с растянутыми кластерами.
• Бесшовная миграция с платформы vVols без простоев.
• Масштабируемые, неизменяемые снимки (immutable snapshots) как для традиционных, так и для современных приложений.

Для получения дополнительной информации о планируемых нововведениях vSAN и vVols рекомендуем посмотреть записи вот этих сессий VMware Explore 2024:

• VMware’s Vision for Storage and Data Protection in VMware Cloud Foundation [VCFB2086LV]
• What’s New with vSAN and Storage Operations in VMware Cloud Foundation [VCFB2085LV]
• vVols and Stretched Clusters with Pure Storage and VMware [VCFB2397LVS]
• Workload Provisioning And Protection Made Easy With VMware And NetApp [VCFB2433LVS]

Менеджеры ИТ-инфраструктуры все яснее осознают важность защиты данных и приложений от постоянно растущих угроз. Программы-вымогатели (ransomware), в частности, становятся всё более разрушительными, требуя надёжных и инновационных решений.

На VMware Explore 2024 в Лас-Вегасе Broadcom представила значительные улучшения VMware Live Recovery, комплексного решения, разработанного для защиты среды VMware Cloud Foundation как от атак вымогателей, так и от традиционных катастроф.

• Быстрота и уверенность в условиях кризиса - VMware Live Recovery предлагает и то, и другое. Когда случаются атаки вымогателей или катастрофы, скорость и уверенность являются решающими факторами для успешного восстановления.
• Унифицированный подход к киберустойчивости - VMware Live Recovery отвечает потребностям в восстановлении как после атак вымогателей, так и при катастрофах. Используя комбинацию механизмов безопасного восстановления, защиты east-west и укрепленной (hardened) инфраструктуры, VMware гарантирует, что критически важные рабочие нагрузки защищены в вашей среде VMware vSphere.
• Ускоренное восстановление и упрощённое использование - VMware Live Recovery предоставляет мощную киберустойчивость и устойчивость данных для VMware Cloud Foundation. Это решение обеспечивает восстановление после атак вымогателей и катастроф в унифицированной системе управления, с ускоренным процессом восстановления и упрощенным потреблением, с гибким лицензированием для различных сценариев и облаков.
• Защита вашей виртуальной среды VMware - с помощью VMware Live Recovery вы можете защищать свою среду VMware на различных платформах: в вашем локальном датацентре, в VMware Cloud на AWS или другом облачном провайдере. Это гарантирует защиту от широкого спектра угроз, включая ransomware, аппаратные сбои и природные катастрофы.

Какие новые возможности были представлены на VMware Explore 2024:

1. Локальное восстановление vSAN
2. Удалённая репликация снимков vSAN
3. Изолированная среда восстановления в собственном датацентре (On-Premises Isolated Recovery Environment, IRE)

Локальное восстановление vSAN

Теперь вы можете применять ускоренное до 16 раз обратное восстановление (failback) из VMware Cloud на AWS, используя локальные снимки VMware как основу для процесса восстановления, восстанавливая только проверенные изменения. Это приводит к 75%-му сокращению времени простоя, минимизируя сбои в работе.

Удалённая репликация снапшотов vSAN

Теперь расширены возможности локальных снимков vSAN для создания удалённых снимков, что позволят сохранять более глубокую историю неизменяемых снимков (до 200) с помощью унифицированного виртуального модуля (Virtual Appliance) для управления. Эта новая функция обеспечивает репликацию vSAN-to-vSAN и позволяет достичь следующих результатов:

• Повышенная устойчивость данных: до 200 точек восстановления на ВМ.
• Снижение простоев, благодаря опыту VMware в оркестрации восстановления.
• Упрощённое управление: единый модуль упрощает процесс.
• Повышенная масштабируемость и эффективность: использование кластеров хранения vSAN улучшает производительность.

Преимущества локальной изолированной среды восстановления (IRE)

Теперь у вас есть гибкость и возможность выбора изоляции VCF (VMware Cloud Foundation) как на локальной инфраструктуре, так и в облаке, что обеспечивает суверенитет данных и соответствие нормативным требованиям. Новая локальная изолированная среда восстановления предоставляет возможности кибервосстановления там, где вам удобно — в изолированной среде восстановления, размещенной в VMware Cloud на AWS, или для клиентов, желающих хранить данные локально, на собственной площадке.

Особенности:

• Гибкость и выбор: выбирайте изолированные "чистые комнаты" VCF локально или в облаке.
• Суверенитет данных: сохраняйте контроль над своими данными и обеспечивайте соответствие требованиям конфиденциальности и местонахождения данных.
• Интеграция полного стека: раскройте потенциал интегрированной киберустойчивости VCF для защиты рабочих нагрузок в любом месте.

Более подробно о новых возможностях VMware Live Recovery вы можете узнать из записанных сессий на VMware Explore.

В этом году на VMware Explore 2024 в Лас-Вегасе компания VMware представила новую версию платформы Tanzu Platform 10. Этот новый релиз предназначен для современных предприятий и направлен на трансформацию управления, обеспечения безопасности и оптимизации приложений с улучшенной гибкостью и возможностями мониторинга. Tanzu Platform 10 позволяет выбирать между Cloud Foundry и Kubernetes в качестве среды выполнения, будь то в публичных или частных облаках. Такая гибкость обеспечивает возможность адаптации Tanzu Platform под конкретные нужды вашего бизнеса. Если вы используете Cloud Foundry, теперь вы можете также подключиться и к экосистеме Kubernetes и воспользоваться надежной интеграцией данных, продолжая использовать уникальные функции Cloud Foundry. Вы также получите более глубокую видимость своих систем благодаря улучшенному пользовательскому интерфейсу и усовершенствованиям в области безопасности, циклов развертывания и создания приложений с поддержкой GenAI.

GenAI для Tanzu Platform теперь в публичной бета-версии

Проект, начавшийся на хакатоне на прошлом VMware Explore, вырос в публичную бета-версию GenAI для Tanzu Platform, запущенную в июне. В VMware рады представить еще больше функций и обновлений в последней публичной бета-версии, включая дополнительные возможности для разработчиков, чтобы быстрее и эффективнее создавать приложения в Tanzu Platform для Cloud Foundry.

На волне успеха GenAI в Tanzu Platform компания VMware объявляет о новых возможностях, которые помогут текущим и будущим клиентам Tanzu Platform создавать корпоративные приложения с поддержкой GenAI. VMware Tanzu AI Solutions — это революционный набор возможностей, доступных в Tanzu Platform, который поддерживает организации в ускорении и масштабировании безопасной поставки интеллектуальных приложений.

Последние функции, доступные в публичной бета-версии, включают:

• Поддержку VMware vSphere, Google Cloud Platform, AWS и Azure
• Безопасный и приватный доступ к совместимому с OpenAI API через Tanzu AI Server
• Брокер для моделей, работающих на VMware Private AI Foundation и моделях сторонних поставщиков
• Развертывание частных больших языковых моделей (LLM) через BOSH в вашей инфраструктуре Tanzu Platform для Cloud Foundry
• Поддержка открытых моделей через vLLM и Ollama, а также поддержка доступа к приватным или ограниченным репозиториям Hugging Face
• Поддержка Nvidia GPU (vGPU и режим pass-through) и Intel Xeon CPU (производительность может варьироваться в зависимости от модели и поколения процессора)

Мультиинфраструктурная видимость теперь доступна в Tanzu Platform для Cloud Foundry

Tanzu Platform 10 предоставляет сквозной мониторинг, позволяя командам платформ отслеживать весь жизненный цикл приложений. От начальных коммитов кода до развертывания в продакшн, вы получите полное представление о производительности, ошибках и использовании ресурсов.

В последнем релизе Tanzu Platform 10 теперь поддерживаются мультиинфраструктурные представления и улучшенная видимость Tanzu Platform для Cloud Foundry, что позволяет инженерам платформ видеть все свои системы и компоненты в одном месте. Это упрощает устранение проблем со "здоровьем приложений" во всех развертываниях Cloud Foundry, включая дополнительные возможности для встраивания проверок здоровья в Tanzu Platform.

Интерфейс Tanzu Platform hub, который объединяет инфраструктуры в едином представлении:

Функции, которые будут доступны в Tanzu Platform for Cloud Foundry 10, включают:

• Просмотр всех платформ (Multi-foundation view): Tanzu Platform предоставляет возможность видеть все ваши платформы в одном консолидированном представлении. Это объединение упрощает управление приложениями на различных платформах, предлагая более четкую картину всей вашей экосистемы.
• Снижение затрат (Cost Savings): Используя интегрированное представление центра Tanzu Platform, команды платформ могут сэкономить деньги за счет сокращения потребности в сторонних продуктах. Эта интеграция не только снижает затраты, но и упрощает операции, повышая эффективность и контроль вашего бизнеса.
• Метрики в одном представлении (At-a-glance metrics): Интуитивно понятная панель управления Tanzu Platform предлагает простые метрики для всех платформ. Эта функция позволяет быстро оценить состояние всей вашей среды Cloud Foundry, включая количество приложений и сервисов, работающих на каждой платформе. Этот всеобъемлющий обзор обеспечивает своевременное выявление и устранение проблем.

Посмотрите демонстрацию работы Tanzu Platform в действии в этом эпизоде подкаста Cloud Foundry Weekly.

Прозрачность безопасности

В сегодняшней среде ограничение угроз безопасности имеет первостепенное значение. Tanzu Platform 10 делает акцент на прозрачной модели безопасности, позволяя командам четко видеть и понимать действующие меры безопасности. Это облегчает обнаружение уязвимостей и соблюдение требований, при этом сохраняется целостность ваших приложений.

Теперь в Tanzu Platform 10 клиенты могут анализировать список компонентов программного обеспечения (SBOM) своих приложений, чтобы выявлять устаревшие библиотеки и быстро предоставлять разработчикам информацию о том, какие действия необходимо предпринять для обновления кода приложения. Это также позволяет инженерам платформ поддерживать актуальность библиотек и обеспечивать непрерывные обновления платформы для снижения рисков безопасности.

Быстрее циклы развертывания с улучшенными возможностями для разработчиков

В основе работы VMware с сообществом лежит поддержка разработчиков. Tanzu Platform 10 представляет улучшенные возможности для разработчиков, предлагая надежные инструменты и интеграции, которые упрощают процесс разработки.

В Tanzu Platform 10 канареечные и прокатные развертывания помогут клиентам улучшить опыт развертывания, повысить продуктивность и ускорить циклы развертывания. Канареечные развертывания позволяют тестировать новую сборку на небольшом объеме пользователей, сохраняя старую сборку для большей части трафика.

Клиенты также могут оценить улучшения в автоматическом масштабировании приложений благодаря переработанной архитектуре CF CLI. Автоматическое масштабирование приложений можно применять к еще большему количеству приложений для увеличения времени запуска и улучшения общей устойчивости приложений.

Непрерывные обновления, сертификации и улучшения платформы

Клиенты могут ожидать более плавных обновлений, более легкого отслеживания процесса ротации сертификатов и многочисленных улучшений платформы, разработанных для повышения удобства использования и производительности. Эти улучшения позволяют вашей платформе оставаться на переднем крае инноваций и быть готовой к удовлетворению меняющихся требований бизнеса.

Также дополнительные сведения о VMware Tanzu Platform 10 вы можете узнать тут и тут.

В VMware на протяжении многих лет прислушивались к клиентам и понимают, насколько важно для них иметь стабильную и безопасную инфраструктуру. Несмотря на то что все больше компаний переходят на последние версии VMware Cloud Foundation (VCF) 5.x, некоторые из них находятся в процессе планирования своих обновлений с VCF 4.x.

Чтобы облегчить этот переход и предоставить больше гибкости, недавно было объявлено о продлении периода общей поддержки VMware vSphere 7.x.

Изначально vSphere 7.x должна была достичь окончания общей поддержки 2 апреля 2025 года. С этим объявлением общий период поддержки был продлен до 2 октября 2025 года.

Продление этой поддержки будет осуществляться с учетом следующих условий:

• В течение периода продленной общей поддержки Broadcom будет стремиться решать любые критические уязвимости в исходном коде, которые могут быть обнаружены. Однако возможность обновления компонентов с открытым исходным кодом, включая обновление до более новой версии пакета, зависит от различных факторов, включая, но не ограничиваясь доступностью патча в upstream и поддержкой версии пакета его разработчиками.
• Broadcom не гарантирует, что будут выпущены обновления для всех выявленных уязвимостей в исходном коде. Broadcom оставляет за собой право не включать исправления ошибок, уязвимостей безопасности или любое другое обслуживание компонентов с открытым исходным кодом, даже если они доступны в upstream.
• Последняя поддерживаемая версия Kubernetes на VCF 4.x (vCenter 7.x) будет минорной версией 1.28. Клиентам, использующим панель управления vSphere IaaS, следует планировать переход на vCenter 8.x до окончания общей поддержки Kubernetes v1.28 28 мая 2025 года. Начиная с vCenter 8.0 Update 3, служба TKG может быть обновлена независимо для поддержки новых версий Kubernetes.
• В vSphere 7.x включен встроенный реестр Harbor, который можно активировать на Supervisor кластере для хранения и обмена образами контейнеров. Поддержка этого встроенного реестра Harbor на vSphere 7.x не будет продлена в период продленной общей поддержки. Клиенты, использующие встроенный реестр Harbor, могут выбрать один из следующих вариантов:
  • Рассмотреть возможность миграции на внешний частный реестр контейнеров на продленный период.
  • Обновиться до последней версии vSphere 8.x и перейти на использование службы Harbor Supervisor.

С ростом числа сценариев использования генеративного AI, а также с существующими рабочими нагрузками AI и машинного обучения, все хотят получить больше мощностей GPU и стремятся максимально эффективно использовать те, которые у них уже есть. В настоящее время метрики использования GPU доступны только на уровне хоста в vSphere, а с помощью модуля vSphere GPU Monitoring вы теперь можете видеть их на уровне кластера. Эта информация имеет большое значение для таких задач, как планирование ёмкости, что оказывает значительное стратегическое влияние на организации, стремящиеся увеличить использование AI.

vSphere GPU Monitoring Fling предоставляет метрики GPU на уровне кластера в VMware vSphere, что позволяет максимально эффективно использовать дорогостоящее оборудование. Он совместим с vSphere версий 7 и 8. Также функционал утилиты также доступен в виде основного патча vCenter 8.0 Update 2 для тех, кто использует более новые версии платформы (то есть, Fling не требуется!). Скачайте плагин здесь и поделитесь своим мнением в разделе Threads на портале community.broadcom.com или по электронной почте vspheregpu.monitoring@broadcom.com.

Пользователям нужно провести установку плагина для объекта Datacenter, после чего они смогут видеть сводные метрики своих GPU для кластеров в этом датацентре. В представлении датацентра пользователь может нажать на «View Details», чтобы увидеть более подробную информацию о распределении и потреблении GPU, а также о типе совместного использования GPU.

Наконец, температура также является важной метрикой для отслеживания, так как долговечность и производительность GPU значительно снижаются, если они слишком долго работают при высокой температуре. Этот Fling также включает и мониторинг температуры:

В VMware Cloud Foundation (VCF) версии 5.2 появилась новая консоль, которая добавляет диагностические возможности в Operations VMware Cloud Foundation (VMware Aria Operations). VMware Cloud Foundation Operations включен в VCF и VMware vSphere Foundation.

Новые функции включают "Общие выводы" и "Рекомендации по безопасности". Кроме того, такие разделы, как "Серверы vCenter", "Хосты ESXi", "Развертывание рабочих нагрузок" и "Кластеры vSAN", которые ранее были доступны в VMware Cloud Foundation Operations, теперь включены для улучшенной видимости. Также улучшена интеграция с VMware Aria Operations for Logs, что предоставляет больше информации о миграциях vMotion и снапшотах. Чтобы включить эту функцию, необходимо подключить Operations к Operations for Logs и хотя бы одному vCenter. При добавлении дополнительных компонентов VMware vSphere Foundation и VCF станут доступны дополнительные наборы данных. Давайте рассмотрим каждый раздел более подробно.

Общие выводы

В новой версии VMware Cloud Foundation Operations объединены диагностические возможности (из Skyline Health Diagnostics, Skyline Advisor и VMware Aria Operations for Logs) в единый интерфейс, представленный в новой консоли. С помощью Skyline можно применять рекомендации по безопасности и эксплуатации на основе версий. Теперь VMware Cloud Foundation Operations и VMware Aria Operations for Logs привязаны к одним и тем же конечным эндпоинтам, что способствует появлению новых диагностических выводов в консоли, уменьшая необходимость в развертывании дополнительного программного обеспечения (сокращает необходимость в Skyline Advisor Collector и виртуальной машине Skyline Health Diagnostics). Эта бесшовная интеграция уменьшает дублирование усилий, о которых упоминалось ранее, и упрощает развертывание и управление средой. В результате получается системный подход к представлению диагностических выводов клиентам.

Вот некоторые распространенные задачи:

• Просмотр всех файндингов
• Определение общего количества ресурсов
• Категоризация выводов по критичности (критические, срочные и предупреждения)
• Классификация по типу:
  • Рекомендации по безопасности
  • Доступность
  • Проверки перед обновлением
  • Диагностика эксплуатации
  • Производительность
• Уточнение их представления с помощью фильтров на основе:
  • Инвентарь VCF
  • Компоненты VCF
  • Тип файндинга
  • Серьезность
  • Возможности:
    • vMotions
    • Снапшоты
    • Развертывание рабочих нагрузок
    • Домены рабочих нагрузок
      • DRS
      • HA

Для доступа к диагностической консоли выберите "Diagnostics" в левой панели навигации. На странице Home -> Overview найдите ссылки на "Appliances Health & Management".

Рисунок 1. Дэшборд главной страницы.

Рисунок 2. Дэшборд диагностики из меню слева.

В основном дэшборде «Overall Findings» вы можете быстро просмотреть все файндинги. Вы можете уточнить их количество, выбрав компоненты в левой панели. Кроме того, вы можете искать конкретные файндинги или использовать подстановочные знаки в строке поиска, расположенной выше списка файндингов.

Рисунок 3. Опции фильтрации и поиска на панели «Diagnostic Findings».

Вы можете углубиться в просмотр конкретных деталей, выбрав отдельный файндинг, например, Last Observed, Affected Objects и Recommendations.

Рисунок 4. Просмотр Last Objerved и Affected Objects.

На вкладке «Affected Objects» вы можете найти имя объекта, время его первого наблюдения (Occurrence Time) и время последней проверки (Check Time). Окружение будет сканироваться каждые четыре часа, и детали на этой вкладке будут обновляться соответственно. Не забудьте учитывать следующую информацию:

Рисунок 5. Просмотр деталей «Affected Objects».

В разделе «Recommendations» вы можете найти версию продукта, в которой проблема была решена, а также статью базы знаний (KB), в которой представлены детали о проблеме, исправлении и воркэраунде.

Рисунок 6. Просмотр рекомендаций по исправленным версиям и статьям базы знаний (KB).

Вот некоторые распространенные сценарии использования:

• Просмотр VMSA и CVE для определения возможных проблем и обновлений для определенного набора серверов.
• Помощь в планировании обновлений vCenter и ESXi для решения нескольких файндингов одновременно.
• Разделение списка файндингов по регионам, чтобы распределить работу среди сотрудников, работающих в разных регионах.

Управление сертификатами

Все сертификаты в среде будут отображены здесь. Эти сертификаты существуют во всех приложениях VMware для обеспечения идентификации приложений (с целью уменьшения риска атак типа «man in the middle»). Поскольку каждое приложение может иметь до трех сертификатов, управление сертификатами занимает много времени и является сложным процессом. С учетом даты истечения срока действия и внешнего центра сертификации, управление графиком обновления и импорта сертификатов может вызывать проблемы.

Когда вы настраиваете консоль диагностики, то заполняется и панель управления сертификатами. Вы можете легко увидеть все сертификаты для конкретного сервера, включая информацию о том, являются ли они самоподписанными или сертификатами CA, а также активны ли они. Для активных сертификатов пользователи могут увидеть оставшееся время до истечения срока действия, что помогает начать процесс обновления сертификатов до их истечения, чтобы предотвратить возможные перебои в работе.

Рисунок 7. Обзор дэшборда управления сертификатами.

Вот некоторые распространенные сценарии использования:

• Проверка наличия «неактивных» сертификатов и их немедленное исправление.
• Просмотр даты истечения срока действия и немедленное исправление самоподписанных сертификатов.
• Превентивное предотвращение истечения срока действия сертификатов.

vCenter

В дэшборде диагностики vCenter вы можете легко просмотреть все vCenter, подключенные к VCF Operations. Здесь объединяются все данные из vCenter, а также данные из VCF Operations. Вы можете быстро проверить операционный статус каждого vCenter. Если какой-либо vCenter не работает, вы можете определить количество затронутых хостов ESXi и виртуальных машин. Кроме того, вы можете увидеть все службы, запущенные на конкретном vCenter. В течение нескольких секунд можно определить, какие службы не работают, устранить проблемы и вернуть их в рабочее состояние. Этот процесс занял бы 30 минут или больше, если бы использовались традиционные методы, такие как проверка vCenter через консоль сервера и файлы журналов. При необходимости можно выбрать отдельные vCenter для более детального исследования.

Рисунок 8. Дэшборд vCenter.

Вот некоторые распространенные сценарии использования:

• Проверка доступности любого vCenter и определение затронутых серверов и виртуальных машин.
• Просмотр служб на каждом vCenter, чтобы убедиться, что все они работают нормально.

Хосты ESXi

Дэшборд ESXi предоставляет важную диагностическую информацию о хостах ESXi. Во-первых, вы можете проверить наличие «неотвечающих ESXi» серверов, так как это вопросы высокого приоритета. Далее, вы можете проверить, находятся ли какие-либо ESXi серверы в режиме обслуживания и определить, должны ли они оставаться в этом режиме или выйти из него. Также важно обратить внимание на серверы ESXi, которые были «отключены» или «не отвечают» в течение длительного времени. При выборе каждого ESXi сервера вы можете получить доступ к настройкам «родительского кластера», что может предоставить ценные сведения о возможных проблемах. В течение нескольких секунд можно выявить проблемы и инициировать необходимые действия по их устранению.

Рисунок 9. Дэшборд ESXi.

Вот некоторые распространенные сценарии использования:

• Выявление всех «не отвечающих» серверов ESXi и их восстановление до нормального состояния.
• Проверка ESXi режиме обслуживания для уверенности в том, что они действительно должны там находиться. Вывод из режима обслуживания как можно скорее для оптимального использования ресурсов.
• Определение «Родительского кластера» конкретного ESXi и проверка правильности всех настроек.

Развертывание рабочих нагрузок

На панели управления развертыванием рабочих нагрузок вы можете просмотреть общие задачи по управлению нагрузкой, такие как «Создать новую виртуальную машину», «Развернуть OVF» и «Клонировать виртуальную машину». Вы можете быстро выявить любые сбои. При просмотре деталей пользователи могут увидеть информацию, такую как «Время запроса», «Имя виртуальной машины», «Инициатор», «vCenter» и «Кластер». С этой информацией вы можете исследовать окружение на наличие потенциальных проблем, выполнить необходимые исправления и уведомить инициаторов о необходимости повторного выполнения их задач.

Рисунок 10. Дэшборд развертывания рабочих нагрузок.

Вот некоторые распространенные сценарии использования:

• Определение всех диагностических файндингов, связанных с развертыванием рабочих нагрузок.
• Проверка любых сбоев для выявления основной причины проблемы.
• Просмотр «инициаторов», чтобы убедиться, что все пользователи правильно назначены.

Миграции vMotion

Технология vMotion существует уже достаточно давно. Вы можете наблюдать за активностью vMotion в списке «recent tasks» в консоли vCenter. Однако ранее не было возможности видеть все события vMotion из одного представления. Теперь у вас есть такая возможность. Вы можете выбрать каждый vCenter, чтобы просмотреть все случаи vMotion, определяя как сбои, так и успешные события. В случае сбоя вы можете просмотреть такие детали, как имя виртуальной машины, источник, назначение и время, что поможет выявить и устранить проблему, предотвращая аналогичные сбои в будущем. Для тех, кто использует HCX (который использует vMotion), также фиксируются все активности HCX vMotion.

Рисунок 11. Дэшборд vMotion.

Вот некоторые распространенные сценарии использования:

• Определение всех диагностических файндингов, связанных с vMotion.
• Просмотр всех локаций, а также каждого vCenter на основе прошлых проблем.
• Проверка исходного и целевого хостов для выявления проблем.

Снапшоты

В диагностической консоли вы можете просмотреть все снапшоты в окружении. Вы сможете определить наиболее проблемные виртуальные машины с проблемами снапшотов, особенно те, которые требуют консолидации. Еще один важный аспект — оценка общего количества снимков для семи наиболее важных виртуальных машин. У вас есть возможность фильтровать успешные и неудачные снимки. Для каждой проблемы, связанной со снимками, вы можете просмотреть такие детали, как виртуальные машины, vCenter, хранилище данных и временная метка. Это должно предоставить достаточно информации, чтобы определить, является ли проблема специфичной для конкретной виртуальной машины или это системная проблема, связанная с vCenter, ESXi или хранилищем данных.

Рисунок 12. Дэшборд снапшотов.

Вот некоторые распространенные сценарии использования:

• Определение всех диагностических файндингов, связанных со снапшотами.
• Просмотр любых сбоев.
• Сопоставление любого сбоя с проблемой ESXi, графиком резервного копирования или другими сбоями (сеть, хранилище и т.д.).

Кластеры vSAN

Раздел «vSAN Health» в диагностической консоли предоставляет обзор состояния инфраструктуры vSAN. Вы можете быстро отфильтровать количество предупреждений «Красного», «Оранжевого» и «Желтого» уровня. При выборе каждого кластера появятся детали о свойствах выбранного кластера, которые помогут убедиться, что все необходимые настройки корректны. Ниже вы можете просмотреть детали каждого предупреждения, что поможет правильно расставить приоритеты и устранить проблемы для обеспечения наилучшей производительности и стабильности кластера vSAN.

Рисунок 13. Панель управления здоровьем vSAN.

Вот некоторые распространенные сценарии использования:

• Просмотр всех предупреждений «Красного», «Оранжевого» и «Желтого» уровня.
• Проверка всех свойств выбранного кластера на правильность настроек.
• Прохождение по всем выводам по отдельности для планирования обновления с целью решения проблем.

После изучения всех функций в диагностической консоли (файндинги, сертификаты, vCenter, ESXi, развертывание рабочих нагрузок, vMotion, снапшоты и кластеры vSAN) вы можете оценить значимость новых дэшбордов. Некоторые из них представляют собой недавно добавленные функции из других продуктов, а другие — это детали существующих панелей, объединенные в этой консоли. Цель заключается в предоставлении ценных сведений с минимальными усилиями по развертыванию и настройке. Это позволит использовать существующие экземпляры Aria Operations и Operations for Logs, что в конечном итоге сэкономит время клиентов на решение проблем и сократит время простоя и обслуживания.

В рамках функционала Configuration Profiles платформы VMware vSphere вы можете создать пользовательское определение аларма, который будет срабатывать, когда один или несколько хостов в кластере не соответствуют заданной конфигурации. Определение аларма можно создать на уровне vCenter или кластера (а также на уровнях папок и объекта datacenter). Для упрощения можно создать одно определение аларма на уровне vCenter, чтобы одно и то же определение применялось ко всем кластерам...

На прошлой неделе мы писали о новых возможностях следующих продуктов:

• VMware NSX 4.2
• Aria Operations 8.18
• Aria Suite Lifecycle 8.18
• Aria Operations for Networks 6.3

Все они стали доступны одновременно с релизом платформы VMware Cloud Foundation 5.2. В состав этого комплексного решения также вошло и средство VMware HCX 4.10, предназначенное для миграции с различных онпремизных инфраструктур (как на платформе vSphere, так и Hyper-V или KVM) в облако на базе VMware Cloud и между облаками.

VMware HCX 4.10.0 является минорным релизом, который предоставляет новые функции, улучшения совместимости и удобства использования, а также обновления безопасности и исправления. Важные изменения касаются лицензионного фреймворка, улучшения управления трафиком, миграции, интерконнекта и поддержки различных систем.

Давайте посмотрим на новые возможности VMware HCX 4.10:

Важная информация

В версии HCX 4.9.0 VMware ввела единый лицензионный фреймворк для активации продуктов VMware Cloud Foundation и VMware vSphere Foundation. При обновлении до HCX 4.10 с версии ниже HCX 4.9.0, ознакомьтесь с изменениями в лицензировании и активации, описанными в заметках к релизу HCX 4.9.0. Всем существующим клиентам HCX, не использующим hyperscaler-облака, рекомендуется обновиться как можно скорее для обеспечения наивысшего уровня поддержки и портируемости продуктов VMware.

Улучшения управления трафиком

• Настраиваемое шифрование транспорта для миграции и трафика расширения сети: по умолчанию трафик миграции и расширения сети HCX зашифрован. В этой версии введена опция Service Mesh для активации или деактивации шифрования для каждого из этих сервисов. Отключение шифрования доступно для безопасных сетей Uplink.
• Generic Receive Offload (GRO): для входящего трафика расширения сети можно настроить GRO в настройках Traffic Engineering для Service Mesh, что улучшает производительность приложений.

Улучшения миграции

• Параметризация сайтов с не-vSphere для OS Assisted Migration (OSAM): теперь можно связывать сайты не на базе vSphere с HCX Connector или HCX Cloud Manager для миграции рабочих нагрузок с помощью OSAM, упрощая процесс миграции.
• HCX Assisted vMotion: новый тип миграции, работающий в сочетании с native cross-vCenter vMotion для оркестрации миграций между хостами VMware ESXi.
• Поддержка новых гостевых ОС для OSAM: Поддерживаются дополнительные операционные системы, такие как RHEL 8.9 и выше, Ubuntu 20.04 и 22.04, а также Rocky Linux 8.4 и выше.
• Массовая миграция (per-VM EVC): включает опцию деактивации Enhanced vMotion Compatibility для отдельных виртуальных машин.
• Миграция тегов vCenter: введена репликация тегов vCenter с исходного сайта на целевой сайт для более удобной настройки.

Улучшения интерконнекта

• HCX Intrasite Control Network: Новый тип сети для связи между HCX Interconnect и WAN Optimization, что разгружает задачи от сети Management Network.
• Конфигурация Compute Profile: HCX проверяет, что все профили сети охватывают все кластеры, чтобы предотвратить ошибки развертывания.

Улучшения расширения сети

• Разрешение пересекающихся подсетей: появилась опция разрешения пересекающихся подсетей для Network Extension, что полезно в случаях, когда сети имеют разные vLAN.

Улучшения совместимости

• VMware Cloud Foundation 5.2: HCX 4.10 совместим с VMware Cloud Foundation 5.2, улучшая масштабируемость и отказоустойчивость.
• VMware vSphere/vSAN 8.0 Update 3: поддержка миграций для виртуальных машин, использующих HW версию 21.
• VMware NSX 4.2: поддержка всех сетевых и миграционных функций в средах vSphere с NSX 4.2.
• VMware vSAN Max: возможность использования хранилищ vSAN Max в качестве целевых для мигрируемых рабочих нагрузок.

Улучшения пользовательского интерфейса

• Интерфейс Site Pairs: Теперь связанные сайты отображаются как отдельные карточки.

• Интерфейс Interconnect: локальные менеджеры Interconnect теперь показывают настройки Network Profile, Compute Profile и Service Mesh в одном месте.

• Конфигурация Service Mesh: включает отдельные мастера для создания Service Mesh для сайтов на основе vSphere и не-vSphere.

Эти улучшения делают VMware HCX 4.10.0 более мощным инструментом для миграции и управления сетями, обеспечивая повышение производительности, безопасности и удобства использования.

Подробнее обо всем этом вы можете почитать в Release Notes.

На днях мы писали о новых возможностях продуктов VMware NSX 4.2 и Aria Operations 8.18, которые стали доступны одновременно с релизом платформы VMware Cloud Foundation 5.2. В состав этого комплексного решения также вошло и средство VMware Aria Operations for Logs 8.18, предназначенное для администраторов, сотрудников технической поддержки и системных инженеров, которые ищут причины проблем различного характера в облачной инфраструктуре на базе VMware Cloud и решают их на базе аналитики лог-файлов.

Давайте посмотрим на новые возможности VMware Aria Operations for Logs 8.18:

Поддержка единого входа (SSO) для VMware vSphere Foundation

В новой версии VMware Aria Operations for Logs 8.18 введена поддержка единого входа (SSO) с использованием VMware vCenter в качестве провайдера SSO. Теперь поддерживается импорт пользователей и групп из SSO провайдера, что упрощает управление доступом.

Улучшения пользовательского опыта

Страницы конфигурации интеграции VMware vSphere и VMware Aria Operations стали более интуитивными и удобными. Это обеспечивает более плавный и упрощенный процесс настройки.

Поддержка JSON для потребления логов

Теперь VMware Aria Operations for Logs поддерживает потребление логов в формате JSON, помимо формата Syslog, и потребление с помощью агента VMware Aria Operations for Logs. Это расширяет возможности работы с логами и улучшает совместимость с различными системами.

Поддержка VMware Aria Operations Cloud Proxy

В данной версии улучшена поддержка VMware Aria Operations Cloud Proxy для потребления и агрегации логов с последующей отправкой в VMware Aria Operations for Logs. Это обеспечивает более эффективное управление логами из облачных сред.

Документация API в формате Swagger

Теперь VMware Aria Operations for Logs поддерживает документацию API в формате Swagger. Это упрощает работу разработчиков и интеграцию с другими системами, предоставляя подробную информацию о доступных API.

Исправления безопасности

В этой версии устранено множество уязвимостей. Подробную информацию о безопасности и влиянии этих уязвимостей на продукты VMware можно найти в базе знаний KB 369221. Эти исправления повышают общую безопасность системы и защищенность данных.

Улучшения производительности

Производительность запросов, содержащих фильтры с полями, извлеченными с помощью регулярных выражений, была оптимизирована. Это улучшает скорость и эффективность работы с логами, особенно при сложных запросах.

Новые пакеты контента

В портале VMware Marketplace теперь доступны пакеты контента для следующих продуктов VMware:

• VMware HCX
• VMware vSphere с Tanzu

Эти пакеты контента позволяют расширить функциональность VMware Aria Operations for Logs и обеспечивают дополнительные возможности для мониторинга и управления логами.

Данные нововведения делают VMware Aria Operations for Logs 8.18 мощным инструментом для управления и анализа логов, улучшая производительность, безопасность и удобство использования.

Подробнее обо всем этом вы можете почитать в Release Notes.

Недавно мы писали о новых возможностях продукта VMware NSX 4.2, который стал доступен одновременно с релизом платформы VMware Cloud Foundation 5.2. В состав этого комплексного решения также вошло и средство VMware Aria Operations 8.18 для управления и мониторинга виртуального датацентра. Напомним также, что о версии Aria Operations 8.16 мы писали вот тут.

Удаленные коллекторы

VMware Aria Operations 8.14 был последним релизом, поддерживающим удаленные коллекторы. В версиях 8.16 и позднее обновления невозможны при наличии удаленных коллекторов. Для обновления необходимо заменить все удаленные коллекторы на облачные прокси. Это изменение улучшит сбор данных и упростит управление.

Устаревание XML в REST API

В следующем крупном релизе VMware Aria Operations поддержка XML в новых API и новых функциях существующих API будет прекращена. Для обмена данными рекомендуется использовать JSON, хотя текущие API продолжат поддерживать XML.

Поддержка облачных платформ и новых интеграций

Поддержка интеграций с облачными платформами Amazon Web Services, Microsoft Azure, Oracle Cloud VMware Solution и Google Cloud Platform будет доступна только через Marketplace. Важно обновить адаптер Google Cloud Platform до версии 8.18 сразу после обновления кластера, чтобы избежать потери данных.

Улучшенная навигация и управление

Введено новое меню навигации, ориентированное на выполнение задач, и средства для управления стеком VMware Cloud Foundation, включая обновление сертификатов, контроль конфигураций и диагностику. На вкладке Overview на главной странице представлены возможности управления и мониторинга VMware Cloud Foundation.

Диагностика и мониторинг

Теперь можно получать информацию о известных проблемах, влияющих на программное обеспечение VMware, и следить за состоянием ключевых случаев использования VMware Cloud Foundation, таких как vMotion, Snapshots и Workload Provisioning. Введены новые функции для контроля и устранения отклонений конфигураций vCenter.

Единый вход и управление лицензиями

Поддержка единого входа (SSO) для VMware vSphere Foundation с возможностью импорта пользователей и групп из провайдера SSO. Управление лицензиями VMware Cloud Foundation и VMware vSphere Foundation теперь доступно в VMware Aria Operations.

Управление сертификатами

Появилось централизованное управление сертификатами для всех компонентов VMware Cloud Foundation. Также есть и возможность мониторинга и получения информации о сертификатах инфраструктуры VMware Cloud Foundation.

Улучшение пользовательского опыта и отчетности

Обновленный опыт работы с инвентарем и виджетами, поддержка просмотра объектов с предками и потомками, возможность фильтрации по возрасту объектов и определениям предупреждений. Возможность добавления до пяти панелей инструментов на главную страницу и их упорядочивания.

Снижение шума предупреждений и улучшение панели инструментов

Введение 20-секундной пиковой метрики, что позволяет получить более четкую видимость данных и уменьшить шум предупреждений. Обновленные панели инструментов, такие как панель изменений VM и панель производительности кластеров, обеспечивают лучшую видимость и взаимодействие.

Управление емкостью и стоимостью

Возможность переопределения метрик для расчета емкости и получения рекомендаций по оптимизации ресурсов. Управление затратами на лицензии VMware по ядрам, а также доступность метрик затрат для проектов и развертываний VMware Aria Automation.

Миграция Telegraf и усиление безопасности

Поддержка сохранения конфигурации плагинов Telegraf при переустановке и усиление безопасности за счет ограничения входящих сетевых подключений и предотвращения несанкционированного доступа.

Улучшения для vSAN и отчеты о соответствии

Поддержка кластера vSAN Max и улучшения виджетов для отображения информации о предках и потомках объектов. Обновления пакетов соответствия для CIS и DISA, поддержка новых версий ESXI и vSphere.

Эти новые возможности и улучшения делают VMware Aria Operations 8.18 более мощным и удобным инструментом для управления виртуальной инфраструктурой, повышая эффективность и безопасность работы с облачными и локальными ресурсами.

Подробнее обо всем этом вы можете почитать в Release Notes.

Недавно мы писали об использовании устройств DPU в современных датацентрах, сегодня поговорим о новых возможностях поддержки устройств Dual DPU.

В последнем релизе платформ Cloud Foundation 5.2 и vSphere 8.0 Update 3 компания VMware представила новинку - поддержку возможностей устройств Dual DPU. Эта функция предназначена для значительного повышения производительности и обеспечения высокой доступности вашей сетевой инфраструктуры.

Почему поддержка Dual DPU важна

С ростом требований к производительности и надежности сетевой инфраструктуры, поддержка Dual DPU в VMware Cloud Foundation 5.2 дает клиентам надежное решение. Увеличивая пропускную способность вдвое и предоставляя гибкие настройки для производительности или высокой доступности, эта функция отвечает потребностям современных центров обработки данных и частных облачных сред. Независимо от того, стремитесь ли вы улучшить производительность сети или обеспечить резервную мощность для критически важных рабочих нагрузок, поддержка Dual DPU обеспечивает универсальность и надежность, необходимые вам.

Основные особенности поддержки Dual DPU

• Управление несколькими DPU на одном хосте

С поддержкой Dual DPU вы теперь можете управлять двумя экземплярами DPU в пределах одного хоста. Это усовершенствование упрощает процесс управления, гарантируя, что оба модуля DPU эффективно обрабатываются без дополнительных сложностей.

• Повышенная производительность и пропускная способность

Одним из самых значимых преимуществ поддержки Dual DPU является увеличение производительности. Поддерживая два DPU на одном хосте, VMware позволяет удвоить пропускную способность. Каждый DPU работает независимо, но вместе они обеспечивают 2-кратное увеличение пропускной способности.

Гибкость в использовании DPU

Новая конфигурация Dual DPU предлагает клиентам гибкость в использовании их DPU:

1. Производительность: оба DPU работают независимо, обеспечивая максимальную пропускную способность. Эта конфигурация идеальна для сред, где производительность критически важна, так как она полностью использует увеличенную полосу пропускания.
2. Высокая доступность: Клиенты могут настроить DPU в состоянии Active-Standby для повышения отказоустойчивости. В этом режиме, если активный DPU выходит из строя, весь трафик бесшовно переключается на резервный DPU, обеспечивая непрерывность обслуживания. Эта конфигурация идеально подходит для критически важных приложений, где время бесперебойной работы имеет первостепенное значение.

Поддержка VMware vSphere Lifecycle Manager

В VMware vSphere 8 Update 3, vSphere Lifecycle Manager (vLCM) включает поддержку конфигураций с двумя DPU. Как и в случае с одиночными DPU, vLCM будет обеспечивать обновление и поддержание в актуальном состоянии версий ESXi для обоих модулей DPU. Эта интегрированная поддержка упрощает управление жизненным циклом и обеспечивает согласованность в вашей инфраструктуре.

В интересах обеспечения удовлетворенности клиентов, компания VMware решила продлить общий период поддержки (general support) для продуктов VMware vSphere 7.x и VMware vSAN 7.x. Изначально установленная дата окончания общей поддержки (End of General Support, EoGS) была назначена на 2 апреля 2025 года, но теперь она продлена на 6 месяцев, до 2 октября 2025 года.

Это продление общего периода поддержки предоставляет клиентам большую гибкость в планировании будущих обновлений. VMware стремится создать надежную среду поддержки и предоставить достаточно времени для стратегического планирования с учетом изменяющихся потребностей клиентов.

Резюме ключевых дат:

* Применимо к поддержке, приобретенной до 6 мая 2024 года.

Для получения более подробной информации или вопросов, пожалуйста, свяжитесь с вашим представителем VMware, партнером-реселлером Broadcom или службой поддержки VMware.

VMware vSphere давно зарекомендовала себя как одна из ведущих платформ для виртуализации, обеспечивая мощные инструменты для управления виртуальными машинами (VM) и инфраструктурой центров обработки данных (ЦОД). В версии VMware vSphere 8 Update 3 была введена новая важная функция — Live Patch. Это нововведение позволяет администраторам вносить критические исправления и обновления безопасности в ядро гипервизора ESXi без необходимости перезагрузки системы или отключения виртуальных машин. В данной статье мы рассмотрим, что такое Live Patching, его преимущества, технические аспекты работы и потенциальные ограничения.

Выход платформы VMware vSphere 8 переопределил подход к управлению жизненным циклом и обслуживанием инфраструктуры vSphere. Решение vSphere Lifecycle Manager упрощает управление образами кластеров, обеспечивает полный цикл управления драйверами и прошивками, а также ускоряет полное восстановление кластера. Управление сертификатами происходит без сбоев, а обновления vCenter можно выполнять с гораздо меньшими простоями по сравнению с прошлыми релизами платформы.

vSphere 8 Update 3 продолжает эту тенденцию снижения и устранения простоев с введением функции vSphere Live Patch.

vSphere Live Patch позволяет обновлять кластеры vSphere и накатывать патчи без миграции рабочих нагрузок с целевых хостов и без необходимости перевода хостов в полный режим обслуживания. Патч применяется в реальном времени, пока рабочие нагрузки продолжают выполняться.

Требования данной техники:

• vSphere Live Patch является опциональной функцией, которую необходимо активировать перед выполнением задач восстановления.
• vCenter должен быть версии 8.0 Update 3 или выше.
• Хосты ESXi должны быть версии 8.0 Update 3 или выше.
• Настройка Enforce Live Patch должна быть включена в глобальных настройках восстановления vSphere Lifecycle Manager или в настройках восстановления кластера.
• DRS должен быть включен на кластере vSphere и работать в полностью автоматическом режиме.
• Для виртуальных машин с включенной vGPU необходимо активировать Passthrough VM DRS Automation.
• Текущая сборка кластера vSphere должна быть пригодна для применения live-патчинга (подробности ниже).

Как работает Live Patching

Кликните на картинку, чтобы открыть анимацию:

Распишем этот процесс по шагам:

• Хост ESXi переходит в режим частичного обслуживания (partial maintenance mode). Частичный режим обслуживания — это автоматическое состояние, в которое переходит каждый хост. В этом особом состоянии существующие виртуальные машины продолжают работать, но создание новых ВМ на хосте или миграция ВМ на этот хост или с него запрещены.
• Новая версия компонентов целевого патча монтируется параллельно с текущей версией.
• Файлы и процессы обновляются за счет смонтированной версии патча.
• Виртуальные машины проходят быструю паузу и запуск (fast-suspend-resume) для использования обновленной версии компонентов.

Не все патчи одинаковы

Механизм vSphere Live Patch изначально доступен только для определенного типа патчей. Патчи для компонента выполнения виртуальных машин ESXi (virtual machine execution component) являются первыми целями для vSphere Live Patch.

Патчи, которые могут изменить другие области ESXi, например патчи VMkernel, изначально не поддерживаются для vSphere Live Patch и пока требуют следования существующему процессу патчинга, который подразумевает перевод хостов в режим обслуживания и эвакуацию ВМ.

Обновления vSphere Live Patches могут быть установлены только на поддерживаемые совместимые версии ESXi. Каждый Live Patch будет указывать, с какой предыдущей сборкой он совместим. vSphere Lifecycle Manager укажет подходящие версии при определении образа кластера. Также вы можете увидеть подходящую версию в репозитории образов vSphere Lifecycle Manager:

Например, patch 8.0 U3a 23658840 может быть применен только к совместимой версии 8.0 U3 23653650. Системы, которые не работают на совместимой версии, все равно могут быть обновлены, но для этого будет использован существующий процесс "холодных" патчей, требующий перевода хостов в режим обслуживания и эвакуации ВМ.

Соответствие образа кластера будет указывать на возможность использования Live Patch.

Быстрое приостановление и возобновление (fast-suspend-resume)

Как упоминалось ранее, патчи для компонента выполнения виртуальных машин в ESXi являются первой целью для vSphere Live Patch. Это означает, что хотя виртуальные машины не нужно эвакуировать с хоста, им нужно выполнить так называемое быстрое приостановление и возобновление (FSR) для использования обновленной среды выполнения виртуальных машин.

FSR виртуальной машины — это ненарушающее работу действие, которое уже используется в операциях с виртуальными машинами при добавлении или удалении виртуальных аппаратных устройств (Hot Add) в работающие виртуальные машины.

Некоторые виртуальные машины несовместимы с FSR. Виртуальные машины, настроенные с включенной функцией Fault Tolerance, машины, использующие Direct Path I/O, и vSphere Pods не могут использовать FSR и нуждаются в участии администратора. Это может быть выполнено либо путем миграции виртуальной машины, либо путем перезагрузки виртуальной машины.

Сканирование на соответствие в vSphere Lifecycle Manager укажет виртуальные машины, несовместимые с FSR, и причину несовместимости:

После успешного восстановления кластера любые хосты, на которых работают виртуальные машины, не поддерживающие FSR, будут продолжать сообщать о несоответствии требованиям. Виртуальные машины необходимо вручную переместить с помощью vMotion или перезагрузить. Только тогда кластер будет полностью соответствовать требованиям (compliant).

Отметим, что vSphere Live Patch несовместим с системами, работающими с устройствами TPM или DPU, использующими vSphere Distributed Services Engine.

Наверняка вы слышали о недавнем обновлении программного обеспечения CrowdStrike для Microsoft Windows, которое вызвало беспрецедентный глобальный сбой по всему миру (а может даже вы были непосредственно им затронуты). Несколько дней назад ИТ-администраторы работали круглосуточно, чтобы восстановить работоспособность тысяч, если не десятков тысяч систем Windows.

Текущий рекомендуемый процесс восстановления от CrowdStrike определенно болезненный, так как он требует от пользователей перехода в безопасный режим Windows для удаления проблемного файла. Большинство организаций используют Microsoft Bitlocker, что добавляет дополнительный шаг к уже и так болезненному ручному процессу восстановления, так как теперь необходимо найти ключи восстановления перед тем, как войти в систему и применить исправление.

Вильям Лам написал об этой ситуации. В течение нескольких часов после новостей от CrowdStrike он уже увидел ряд запросов от клиентов и сотрудников на предмет наличия автоматизированных решений или скриптов, которые могли бы помочь в их восстановлении, так как требование к любой организации вручную восстанавливать системы неприемлемо из-за масштабов развертываний в большинстве предприятий. Ознакомившись с шагами по восстановлению и размышляя о том, как платформа vSphere может помочь пользователям автоматизировать то, что обычно является ручной задачей, у него возникло несколько идей, которые могут быть полезны.

Скрипты, предоставленные в этой статье, являются примерами. Пожалуйста, тестируйте и адаптируйте их в соответствии с вашей собственной средой, так как они не были протестированы официально, и их поведение может варьироваться в зависимости от среды. Используйте их на свой страх и риск.

Платформа vSphere обладает одной полезной возможностью, которая до сих пор не всем известна, позволяющей пользователям автоматизировать отправку нажатий клавиш в виртуальную машину (VM), что не требует наличия VMware Tools или даже запущенной гостевой операционной системы.

Чтобы продемонстрировать, как может выглядеть автоматизированное решение для устранения проблемы CrowdStrike, Вильям создал прототип PowerCLI-скрипта под названием crowdstrike-example-prototype-remediation-script.ps1, который зависит от функции Set-VMKeystrokes. В настройке автора работает Windows Server 2019 с включенным Bitlocker, и он "смоделировал" директорию и конфигурационный файл CrowdStrike, которые должны быть удалены в рамках процесса восстановления. Вместо загрузки в безопасный режим, что немного сложнее, автор решил просто загрузиться в установщик Windows Server 2019 и перейти в режим восстановления, что позволило ему применить тот же процесс восстановления.

Ниже представлено видео, демонстрирующее автоматизацию и шаги, происходящие между PowerCLI-скриптом и тем, что происходит в консоли виртуальной машины. Вручную никакие действия не выполнялись:

В зависимости от вашей среды и масштаба, вам может потребоваться настроить различные значения задержек, и это следует делать в тестовой или разработческой среде перед развертыванием поэтапно.

В качестве альтернативы, автор также рекомендует и немного другой подход. Один из клиентов создал кастомный WindowsPE ISO, который содержал скрипт для удаления проблемного файла CrowdStrike, и всё, что им нужно было сделать, это смонтировать ISO, изменить порядок загрузки с жесткого диска на CDROM, после чего ISO автоматически выполнил бы процесс восстановления, вместо использования безопасного режима, что является довольно умным решением.

В любом случае, вот пример фрагмента PowerCLI-кода, который реконфигурирует виртуальную машину (поддерживается, когда ВМ выключена) для монтирования нужного ISO из хранилища vSphere и обновляет порядок загрузки так, чтобы машина автоматически загружалась с ISO, а не с жесткого диска.

$vmName = "CrowdStrike-VM"
$isoPath = "[nfs-datastore-synology] ISO/en_windows_server_version_1903_x64_dvd_58ddff4b.iso"
$primaryDisk = "Hard disk 1"

$vm = Get-VM $vmName
$vmDevices = $vm.ExtensionData.Config.Hardware.Device

$cdromDevice = $vmDevices | where {$_.getType().name -eq "VirtualCdrom"}
$bootDevice = $vmDevices | where {$_.getType().name -eq "VirtualDisk" -and $_.DeviceInfo.Label -eq $primaryDisk}

# Configure Boot Order to boot from ISO and then Hard Disk
$cdromBootDevice = New-Object VMware.Vim.VirtualMachineBootOptionsBootableCdromDevice
$diskBootDevice = New-Object VMware.Vim.VirtualMachineBootOptionsBootableDiskDevice
$diskBootDevice.DeviceKey = $bootDevice.key

$bootOptions = New-Object VMware.Vim.VirtualMachineBootOptions
$bootOptions.bootOrder = @($cdromBootDevice,$diskBootDevice)

# Mount ISO from vSphere Datastore
$cdromBacking = New-Object VMware.Vim.VirtualCdromIsoBackingInfo
$cdromBacking.FileName = $isoPath

$deviceChange = New-Object VMware.Vim.VirtualDeviceConfigSpec
$deviceChange.operation = "edit"
$deviceChange.device = $cdromDevice
$deviceChange.device.Backing = $cdromBacking
$deviceChange.device.Connectable.StartConnected = $true
$deviceChange.device.Connectable.Connected = $true

$spec = New-Object VMware.Vim.VirtualMachineConfigSpec
$spec.deviceChange = @($deviceChange)
$spec.bootOptions = $bootOptions

$task = $vm.ExtensionData.ReconfigVM_Task($spec)
$task1 = Get-Task -Id ("Task-$($task.value)")
$task1 | Wait-Task | Out-Null

Чтобы подтвердить, что изменения были успешно применены, вы можете использовать интерфейс vSphere или следующий фрагмент PowerCLI-кода:

$vm = Get-VM $vmName
$vm.ExtensionData.Config.BootOptions | Select BootOrder
$vm | Get-CDDrive | select IsoPath

Остается только запустить виртуальную машину, а затем, после завершения восстановления, можно отменить операцию, размонтировав ISO и удалив конфигурацию порядка загрузки, чтобы вернуть исходное поведение виртуальной машины.

Автор сайта virten.net сделал интересную и полезную страницу, где вы можете отслеживать выход свежих релизов продуктов VMware, включая VMware vSphere / ESXi / vCenter, NSX, Aria и другие. Называется эта штука VMware Product Release Tracker (vTracker):

Ссылки, которые позволят вам это использовать в удобном формате:

• vTracker RSS Feed
• vTracker JSON Export
• vTracker CSV Export
• vTracker Table (новое)

Надо сказать, что информация тут обновляется только про финальные релизы, доступные на сайте Broadcom в режиме General Availability (GA), поэтому если вам нужны бета-версии различных решений - отслеживать их нужно отдельно.

Среди новых возможностей последнего обновления платформы виртуализации VMware vSphere 8 Update 3 появилась интересная новая функция, которая позволяет удалять снапшоты виртуальных машин, которые старше некоторого количества дней, которое задается при выполнении этой операции.

Если же вы хотите более глубокого уровня автоматизации, то вы можете применять политики snapshot retention policies с использованием виртуального модуля VMware Event Broker Appliance (VEBA).

Вы можете объединить эту новую возможность в vSphere 8.0 Update 3 с существующей задачей планирования vSphere (Scheduled Tasks), которая периодически очищает существующие снимки, и администраторы теперь имеют дополнительную возможность для быстрой установки возраста снимка, который нужно удалить, без необходимости создавать или полагаться на пользовательский скрипт, который должен быть создан вне сервера vCenter.

Хотя это может показаться незначительной функцией, она определенно улучшает управление операциями для администраторов, позволяя им гарантировать оптимальную работу и не беспокоиться о том, что снимок виртуальной машины сохранится дольше, чем это требуется по политикам.

Среди новых возможностей VMware vSphere 8 Update 3 было улучшение механизма быстрого обновления vCenter Reduced Downtime (анонсирован он был еще в vSphere 8 Update 2). Сегодня мы рассмотрим его подробнее.

Обновление с сокращением времени простоя (Reduced Downtime Update, RDU) использует метод миграции для перехода с одной сборки vCenter на более новую сборку vCenter. Это похоже на существующий метод выполнения крупного обновления vCenter, например, с версии 7 на версию 8, но имеет значительное отличие.

При использовании метода на основе миграции, развертывается новый виртуальный модуль vCenter, и все данные и конфигурации vCenter копируются с текущего vCenter на новый экземпляр последней версии. Основное отличие заключается в том, что во время этой фазы копирования данных и конфигурации текущий vCenter и все его службы остаются онлайн, и vCenter может продолжать свою работу. При этом время простоя службы vCenter составляет всего несколько минут, в этот промежуток текущие службы vCenter останавливаются, а новые службы vCenter запускаются. Обычно это занимает менее 5 минут.

Обновление vCenter с сокращением времени простоя можно использовать для обновления любой версии и топологии vCenter 8 до версии 8 Update 3 или более поздней.

Что нового в vSphere 8 Update 3 для RDU?

Новая поддержка топологий

В vSphere 8 Update 3, обновление vCenter с сокращением времени простоя поддерживает все топологии развертывания vCenter:

• Self-managed: ВМ vCenter управляется самостоятельно.
• Non self-managed: ВМ vCenter управляется другим vCenter (должен быть версии 7.0 или более поздней).
• Связанный режим (Enhanced Linked Mode): два или более экземпляра vCenter, участвующие в одном домене SSO. Не обновляйте несколько экземпляров vCenter параллельно, если они связаны через Enhanced Linked Mode.
• vCenter HA: экземпляры vCenter, настроенные для высокой доступности.
  • vCenter HA автоматически удаляется перед началом обновления и автоматически реактивируется после завершения обновления.
  • Обе топологии self-managed и non self-managed для vCenter HA поддерживаются для обновления с сокращением времени простоя.
  • Экземпляры vCenter HA должны быть как минимум версии vCenter 8 Update 2, чтобы позволить обновлению RDU координировать операцию. Для версий ранее vCenter 8 Update 2, вы можете вручную деактивировать vCenter HA, использовать обновление RDU и вручную реактивировать vCenter HA.

Вам не нужно сначала обновляться до vCenter 8 Update 3, чтобы начать использовать обновление RDU. Вы можете использовать обновление с сокращением времени простоя для вышеуказанных топологий, чтобы обновить экземпляры vCenter, работающие на версии 8.0 и более поздних, до версии 8.0 Update 3 и более поздних. Например, вы можете использовать обновление с сокращением времени простоя, чтобы обновить vCenter 8 Update 1 в режиме Enhanced Linked Mode до vCenter 8 Update 3.

Автоматическое переключение

У вас есть новая опция для автоматического завершения фазы переключения, либо вы можете вручную инициировать фазу переключения.

Дункан Эппинг опубликовал интересный пост, касающийся изменений в интерфейсе vSAN Data Protection, произошедших в новой версии пакета обновлений VMware vSphere 8 Update 3.

Впервые развернув vSphere/vSAN 8.0 U3, он сразу же начал искать интерфейс vSAN Data Protection. Он не смог его найти, но подумал, что это из-за использования какой-то странной альфа-версии продукта. Теперь, когда продукт вышел, эта функция должна быть доступна из коробки, верно?

Нет, не так. Вам нужно развернуть виртуальный модуль (Virtual Appliance), чтобы эта функция появилась в интерфейсе. Этот модуль можно найти в разделе «Drivers and Tools» в разделе загрузок vSphere Hypervisor, который находится по основными ссылками на дистрибутивы vSphere. Он называется «VMware vSAN Snapshot Service Appliance». Текущая версия называется «snapservice_appliance-8.0.3.0-24057802_OVF10.ova». Вам нужно развернуть этот OVA, при это настоятельно рекомендуется запросить для него DNS-имя и правильно зарегистрировать его. Автор возился с файлом hosts на VCSA и забыл добавить имя в локальный файл hosts на своем ноутбуке, из-за чего возникли странные проблемы.

Еще одна вещь, на которую стоит обратить внимание: документация предлагает загрузить сертификаты и скопировать текст для модуля. Это не то, что большинство из нас делает ежедневно. Вы можете просто открыть веб-браузер и использовать следующий URL «https://<имя вашего сервера vCenter>/certs/download.zip», чтобы загрузить сертификаты, а затем распаковать загруженный файл. Более подробную информацию можно найти здесь.

Внутри будут сертификаты, и если вы откроете сертификат в подходящем текстовом редакторе, вы сможете скопировать/вставить его в экран развертывания для OVA.

Теперь, когда вы развернули OVA и все правильно настроено, вы должны увидеть успешное выполнение задачи, а точнее две: загрузка плагина и развертывание плагина, как показано на следующем скриншоте.

Если вы получите сообщение об ошибке «error downloading plug-in», вероятно, это связано с одной из двух причин:

• Файлы DNS / Hosts настроены некорректно, в результате чего URL недоступен. Убедитесь, что вы можете разрешить URL.
• Отпечаток (thumbprint) сертификата был неправильно скопирован/вставлен. Здесь есть целый раздел по устранению этой проблемы.

Недавно мы писали о новых возможностях пакета обновлений платформы виртуализации VMware vSphere 8 Update 3. Сегодня мы более детально рассмотрим, что нового там появилось в плане поддержки карт GPU.

Новые функции охватывают несколько областей, начиная с использования vGPU-профилей разных типов и размеров вместе и заканчивая внесением изменений в расширенные параметры DRS, которые определяют, как ВМ с поддержкой vGPU будет обрабатываться со стороны vMotion, например. Все эти улучшения направлены на упрощение жизни системных администраторов, дата-сайентистов и других пользователей, чтобы они могли использовать свои рабочие нагрузки на платформах vSphere и VCF.

Гетерогенные типы vGPU-профилей с разными размерами

В VMware vSphere мы можем назначить машине vGPU-профиль из набора заранее определенных профилей, чтобы предоставить ей определенную функциональность. Набор доступных vGPU-профилей появляется после установки NVIDIA vGPU менеджера/драйвера на уровне хоста в ESXi посредством vSphere Installation Bundle (VIB).

Эти vGPU-профили называются профилями типа C в случае, если профиль предназначен для интенсивной вычислительной работы, такой как обучение моделей машинного обучения. Существуют и несколько других типов vGPU-профилей, среди которых Q (Quadro) для графических рабочих нагрузок являются одними из самых популярных. Буквы «c» и «q» стоят в конце названия vGPU-профиля, отсюда и название этого типа.

В предыдущем обновлении vSphere 8 Update 2 мы могли назначать машине vGPU-профили, которые предоставляли поддержку различных видов функциональности, используя при этом одно и то же устройство GPU. Ограничением в этой версии vSphere было то, что они должны были быть vGPU-профилями одного и того же размера, например, те, которые заканчиваются на 8q и 8c. Здесь «8» представляет количество гигабайт памяти на самом GPU (иногда называемой framebuffer-памятью), которая назначена ВМ, использующей этот vGPU-профиль. Это значение может изменяться в зависимости от модели основного GPU.

При использовании GPU A40 или L40s мы можем иметь vGPU-профиль типа C, предназначенный для вычислительно интенсивной работы, такой как машинное обучение, и vGPU-профиль типа Q (предназначенный для графической работы), назначенные разным ВМ, которые делят один и тот же физический GPU на хосте.

Теперь в vSphere 8 Update 3 можно продолжать смешивать эти разные типы vGPU-профилей на одном физическом GPU, а также иметь vGPU-профили разного размера памяти, которые делят один и тот же GPU.

В качестве примера новой функциональности vSphere 8 Update 3: ВМ1 с vGPU-профилем l40-16c (для вычислительных нагрузок) и ВМ2 с vGPU-профилем l40-12q (для графических нагрузок) делят одно и то же устройство L40 GPU внутри хоста. Фактически, все вышеупомянутые виртуальные машины делят одно и то же физическое устройство L40 GPU.

Это позволяет лучше консолидировать рабочие нагрузки на меньшее количество GPU, когда рабочие нагрузки не потребляют весь GPU целиком. Возможность размещения гетерогенных типов и размеров vGPU-профилей на одном устройстве GPU применяется к GPU L40, L40s и A40 в частности, так как эти GPU имеют двойное назначение. То есть они могут обрабатывать как графические, так и вычислительно интенсивные задачи, в то время как GPU H100 предназначен исключительно для вычислительно интенсивных задач.

Включение настроек кластера для DRS и мобильности ВМ с vGPU

В vSphere Client версии 8.0 U3 появились новые настройки кластера, которые предоставляют более удобный метод настройки расширенных параметров для кластера DRS. Вы можете установить ограничение по времени приостановки ВМ, которое будет допускаться для машин с vGPU-профилями, которым может потребоваться больше времени, чем по умолчанию, для выполнения vMotion. Время приостановки по умолчанию для vMotion составляет 100 секунд, но этого может быть недостаточно для некоторых ВМ с большими vGPU-профилями. Дополнительное время требуется для копирования памяти GPU на целевой хост. Вы также можете узнать оценочное время приостановки для вашей конкретной ВМ с поддержкой vGPU в vSphere Client. Для получения дополнительной информации о времени приостановки, пожалуйста, ознакомьтесь с этой статьей.

В vSphere 8 Update 3 появился более удобный пользовательский интерфейс для настройки расширенных параметров для кластера DRS, связанных с vMotion виртуальных машин.

Прежде чем мы рассмотрим второй выделенный элемент на экране редактирования настроек кластера ниже, важно понять, что vGPU как механизм доступа к GPU является одной из множества техник, которые находятся в "спектре проброса устройств" (Passthrough spectrum). То есть, vGPU на самом деле является одной из форм прямого доступа. Возможно, вы считали, что подходы прямого проброса и vGPU сильно отличаются друг от друга до настоящего времени, так как они действительно разделены в vSphere Client при выборе добавления нового PCIe-устройства к ВМ. Однако, они тесно связаны друг с другом. Фактически, vGPU ранее назывался "опосредованным пробросом" (mediated passthrough). Этот спектр использования прямого доступа различными способами показан здесь.

Именно поэтому в vSphere Client на выделенном участке экрана ниже используются термины «Passthrough VM» и «Passthrough Devices». Эти термины на самом деле относятся к виртуальным машинам с поддержкой vGPU – и таким образом, обсуждение касается включения DRS и vMotion для виртуальных машин с поддержкой vGPU на этом экране. vMotion не разрешен для виртуальных машин, использующих фиксированный прямой доступ, как показано на левой стороне диаграммы выше.

Новая функция интерфейса позволяет пользователю включить расширенную настройку vSphere под названием «PassthroughDrsAutomation». С включенной этой настройкой, при соблюдении правил по времени приостановки, виртуальные машины в этом кластере могут быть перемещены vMotion на другой хост по решению DRS. Для получения дополнительной информации об этих расширенных настройках DRS, пожалуйста, ознакомьтесь с этой статьей.

Доступ к медиа-движку GPU

Единый медиа-движок на GPU может использоваться виртуальной машиной, которая хостит приложение, которому требуется выполнять транскодирование (кодирование/декодирование) на GPU, а не на более медленном CPU, например, для видео-приложений.

В vSphere 8 Update 3 поддерживается новый vGPU-профиль для виртуальных машин, которым требуется доступ к медиа-движку внутри GPU. Только одна виртуальная машина может использовать этот медиа-движок. Примеры таких vGPU-профилей («me» означает media engine):

• a100-1-5cme (один срез)
• h100-1-10cme (два среза)

Более высокая скорость vMotion виртуальных машин с большими vGPU-профилями

Новые улучшения в vMotion позволяют нам увеличивать пропускную способность для сети vMotion со скоростью 100 Гбит/с до 60 Гбит/с для vMotion виртуальной машины, к которой подключен современный GPU (H100, L40S), что сокращает время vMotion. Это не относится к GPU A100 и A30, которые относятся к более старой архитектуре (GA100).

Новые технические документы и рекомендации по проектированию GPU с VMware Private AI Foundation with NVIDIA

Недавно были выпущены два важных публикации авторами VMware. Агустин Маланко Лейва и команда опубликовали решение VMware Validation Solution для инфраструктуры Private AI Ready Infrastructure, доступное здесь.

Этот документ предоставляет подробное руководство по настройке GPU/vGPU на VMware Cloud Foundation и многим другим факторам для организации вашей инфраструктуры для развертывания VMware Private AI.

Одним из ключевых приложений, которое будут развертывать в первую очередь в инфраструктуре VMware Private AI Foundation с NVIDIA, является генерация с дополненным извлечением или RAG. Фрэнк Деннеман и Крис МакКейн подробно рассматривают требования к безопасности и конфиденциальности и детали реализации этого в новом техническом документе под названием VMware Private AI – Privacy and Security Best Practices.

Недавно мы писали о новых возможностях обновленной версии платформы VMware vSphere 8.0 Update 3, а также о том, что нового появилось в плане основных функций хранилищ (Core Storage). Сегодня мы расскажем о новой версии решения VMware vSphere IaaS Control Plane 8.0.

Для начала - что это за решение? VMware внедрила декларативный API в vSphere, чтобы обеспечить современный опыт IaaS для потребителей облачных услуг. Решение vSphere IaaS Control Plane основывается на работе, проделанной в рамках инициативы vSphere with Tanzu, и расширяет её новым набором возможностей IaaS.

Давайте посмотрим, что нового появилось с выпуском vSphere 8 Update 3.

Независимая служба TKG Service

VMware представляет независимую службу TKG Service, которая отделена от vCenter и реализована как основная служба Supervisor Service. Это позволит выпускать асинхронные обновления сервиса и предоставлять новые версии Kubernetes быстрее, чем когда-либо.

Администраторы смогут обновлять TKG Service без необходимости обновлять Supervisor или vCenter, чтобы без проблем получать и использовать новые версии Kubernetes. Эти версии затем могут быть использованы непосредственно потребителями услуг.

Local Consumption Interface (LCI)

Интерфейс потребления облака (Cloud Consumption Interface, CCI) в Aria Automation предоставляет пользовательский интерфейс для создания виртуальных машин, кластеров TKG, балансировщиков нагрузки и запросов постоянных томов (Persistent Volume Claims).

Этот интерфейс теперь доступен в vCenter для каждого отдельного пространства имен. Пользовательский интерфейс поддерживает сложные спецификации для виртуальных машин и кластеров TKG, автоматически генерируя YAML для пользователей, которые хотят взаимодействовать с API напрямую. Интерфейс виртуальной машины поддерживает создание секретов и configmap для хранения конфигурации облака для настройки экземпляра виртуальной машины. Мастер создания кластеров расширен для поддержки сложных типов кластеров, которые могут включать смешанные рабочие узлы с конфигурациями GPU и без GPU.

Автомасштабирование для кластеров Kubernetes

VMware представила автоматическое масштабирование для кластеров Kubernetes с использованием Cluster Autoscaler. Это позволит кластерам Kubernetes соответствовать текущим потребностям, уменьшать количество узлов при низкой загрузке и увеличивать их количество при росте запросов. Рабочие узлы будут автоматически добавляться, когда ресурсов недостаточно для выполнения планирования подов.

Cluster Autoscaler может быть установлен как стандартный пакет с использованием kubectl или tanzu cli. Версия пакета должна соответствовать минорным версиям Kubernetes, например, чтобы установить пакет на кластер Kubernetes версии v1.26.5, необходимо установить пакет Cluster Autoscaler версии v1.26.2.

Минимально требуемая версия для Cluster Autoscaler — v1.25.

Поддержка растянутых кластеров vSAN Stretched Cluster

Одной из самых востребованных опций конфигурации была возможность развертывания Supervisor на растянутом кластере vSAN, охватывающем два физических местоположения или сайта. В этом релизе VMware учла основные требования для поддержки этой реализации, однако есть некоторые моменты, которые следует учитывать.

Основное внимание следует уделить доступности etcd, который является основной базой данных, хранящей все данные кластера Kubernetes. Etcd использует механизм кворума, что означает, что для его работы необходимо, чтобы более половины реплик были доступны в любое время. Поэтому нет смысла распределять нечетное количество виртуальных машин с Control Pane (CP) по двум сайтам. Вместо этого, для развертывания Active/Active, VMware рекомендует:

• Три виртуальные машины CP Supervisor (SV CP) должны быть размещены на одном сайте, при этом этот сайт может быть любым из двух, поскольку оба сайта активны.
• Все виртуальные машины CP любого кластера TKG должны быть размещены на одном сайте, который может быть любым из двух.

Чтобы контролировать размещение, администратору необходимо настроить правила Affinity rules VM-host для каждого набора связанных виртуальных машин, чтобы привязать виртуальную машину к определенному сайту.

Администраторы также должны создать политику растянутого кластера vSAN с определенными настройками, такими как толерантность к сбоям сайта, установленная на двойное зеркалирование сайта, и включенное принудительное предоставление ресурсов. Поскольку политика растянутого кластера vSAN является требованием для библиотек контента и самого Supervisor, сначала необходимо включить растянутый кластер vSAN, а затем уже Supervisor.

Из-за сложности этой архитектуры VMware настоятельно рекомендует следовать документации по передовым методикам, которая есть для этого случая.

Автоматическая ротация сертификатов Supervisor

Еще одна новая функция, которую VMware добавила в этом выпуске, — автоматическая ротация сертификатов Supervisor. По умолчанию сертификаты Supervisor действительны в течение года после первоначального развертывания. Ранее клиенты могли заменять сертификаты, выполняя ряд ручных шагов. Чтобы упростить этот процесс, его автоматизировали, и сертификаты будут просто заменяться по мере приближения их срока истечения без вмешательства пользователя.

Аларм сработает только в случае, если процесс автоматического обновления не удастся, и это будет видно в интерфейсе vCenter. По умолчанию процесс попытается обновить сертификат снова через 12 часов. Как только замена будет успешной, алерт исчезнет.

Пользователи также могут решить заменить сертификат вручную.

Расширенная конфигурация класса виртуальных машин (VM Class Expanded Configuration)

Пользовательский интерфейс класса виртуальных машин (VM Class) в vCenter был обновлен для поддержки значительно расширенного набора опций конфигурации оборудования. Перемещение конфигурации оборудования в класс виртуальных машин (VM Class) упрощает файл спецификации виртуальной машины, позволяя пользователям ссылаться на один класс виртуальной машины как на шаблон для полной спецификации, а не настраивать отдельные параметры напрямую.

Теперь администраторы имеют детальный контроль над конфигурацией оборудования, доступной для пользователей среды самообслуживания. Конфигурация оборудования более точно соответствует моделям потребления в публичных облаках.

Резервное копирование и восстановление кластера

Velero теперь является основным сервисом, включенным в Supervisor. Этот сервис координирует резервное копирование и восстановление как кластера Supervisor, так и любых развернутых кластеров TKG. Velero необходимо устанавливать на отдельные кластеры TKG через CLI. Резервное копирование и восстановление также выполняются через CLI. Резервное копирование и восстановление Supervisor осуществляется через интерфейс vCenter.

Сервис виртуальных машин (VM Service) – резервное копирование и восстановление виртуальных машин

Служба VM Service теперь включает возможность резервного копирования и восстановления виртуальных машин с использованием любого программного обеспечения VMware Advanced Data Protection. Этот метод не требует изменений в вашем инструменте резервного копирования или специальной конфигурации. Резервное копирование можно выполнять на уровне виртуальных машин или для всего пространства имен. Для пространства имен вы просто указываете пул ресурсов, который поддерживает пространство имен в vCenter.

Когда виртуальная машина развертывается с использованием VM Service, в Supervisor создаются объекты пользовательских ресурсов, которые определяют состояние виртуальных машин, а также поддерживающих объектов, которые облегчают начальную настройку виртуальной машины. Эти метаданные должны быть восстановлены как часть процесса резервного копирования/восстановления.

Виртуальные машины, развернутые с использованием VM Service, теперь сохраняют в полях Extra-Config всю информацию, необходимую для воссоздания метаданных Supervisor. Этот процесс регистрации автоматический и происходит при восстановлении. Если автоматическая регистрация по какой-либо причине не удается, например, из-за отсутствия политики хранения или класса виртуальных машин, доступен API для ручного запуска регистрации после устранения проблемы.